Two fixes for delayed execution
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
 |
Two fixes for delayed execution
by Norbert Nemec
::
Rate this Message:
Hi there,
I identified two different problems with the delayed execution. One is general, the other Qt-specific patch 0001: I once had a segfault during exiting. Turned out that the "static list<SCM> destroy_list" in Guile/Scheme/object.cpp was deleted before the "static array<object> delayed_queue". If the latter still contains objects (which happens once every blue moon) these are added to the former, which does not exist any more. => CRASH. The solution is a new function clear_pending_events which is called before exit(0) in quit. Should be relevant for TeXmacs in general, even though it might be an extremely rare event. patch 0002: turns out that a trivial swap of a "<" caused the strange sluggishness with the new delayed execution that I encountered. The fix is just as trivial... Greetings, Norbert From e75324a558b9eac3af802b3debaad797f560f90b Mon Sep 17 00:00:00 2001 From: Norbert Nemec <Norbert@...> Date: Mon, 12 Oct 2009 14:11:04 +0100 Subject: [PATCH 1/2] Clear pending events before exiting. --- src/src/Guile/Scheme/object.cpp | 7 +++ src/src/Guile/Scheme/object.hpp | 1 + src/src/Plugins/Qt/qt_gui.cpp | 72 ++++++++++++++++++--------------- src/src/Texmacs/Server/tm_server.cpp | 3 +- 4 files changed, 49 insertions(+), 34 deletions(-) diff --git a/src/src/Guile/Scheme/object.cpp b/src/src/Guile/Scheme/object.cpp index b9a5369..ceb0530 100644 --- a/src/src/Guile/Scheme/object.cpp +++ b/src/src/Guile/Scheme/object.cpp @@ -413,4 +413,11 @@ exec_pending_commands () { } } } + +void +clear_pending_commands () { + delayed_queue= array<object> (0); + start_queue= array<int> (0); +} + #endif // QTTEXMACS diff --git a/src/src/Guile/Scheme/object.hpp b/src/src/Guile/Scheme/object.hpp index 0ed81c8..4be726b 100644 --- a/src/src/Guile/Scheme/object.hpp +++ b/src/src/Guile/Scheme/object.hpp @@ -147,6 +147,7 @@ bool exec_file (url u); void exec_delayed (object cmd); void exec_delayed_pause (object cmd); void exec_pending_commands (); +void clear_pending_commands (); object call (const char* fun); object call (const char* fun, object a1); diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/qt_gui.cpp index fd29e99..82be74a 100755 --- a/src/src/Plugins/Qt/qt_gui.cpp +++ b/src/src/Plugins/Qt/qt_gui.cpp @@ -63,7 +63,7 @@ void qt_gui_rep::get_extents (SI& width, SI& height) { QDesktopWidget* d= QApplication::desktop(); int w = d->width(); // returns desktop width - int h = d->height(); // returns desktop height + int h = d->height(); // returns desktop height width = ((SI) w) * PIXEL; height= ((SI) h) * PIXEL; } @@ -121,7 +121,7 @@ qt_gui_rep::get_selection (string key, tree& t, string& s) { } s= ""; t= "none"; - + if (owns) { if (selection_t->contains (key)) { t= copy (selection_t [key]); @@ -130,13 +130,13 @@ qt_gui_rep::get_selection (string key, tree& t, string& s) { } return false; } - + QString originalText = cb->text(mode); QByteArray buf = originalText.toAscii(); if (!(buf.isEmpty())) { s << string(buf.constData(), buf.size()); } - + t= tuple ("extern", s); return true; } @@ -153,11 +153,11 @@ qt_gui_rep::set_selection (string key, tree t, string s) { //XSetSelectionOwner (dpy, XA_PRIMARY, win, CurrentTime); //if (XGetSelectionOwner(dpy, XA_PRIMARY)==None) return false; selection= as_charp (s); - + QClipboard *clipboard = QApplication::clipboard(); QString originalText = clipboard->text(); - - clipboard->setText(selection); + + clipboard->setText(selection); } return true; } @@ -218,23 +218,23 @@ void gui_interpose (void (*r) (void)) { the_interpose_handler= r; } void qt_gui_rep::update () { - // this is called by doUpdate, which in turns is fired by a timer activated in + // this is called by doUpdate, which in turns is fired by a timer activated in // needs_update, and ensuring that interpose_handler is run during a pass in the eventloop - // afterwards we reactivate the timer with a pause (see FIXME below) - + // afterwards we reactivate the timer with a pause (see FIXME below) + if (the_interpose_handler) the_interpose_handler(); - + qt_update_flag = false; - interrupted = false; - + interrupted = false; + updatetimer->start (1000/6); - + // FIXME: we need to ensure that the interpose_handler is run at regular intervals (1/6th of sec) - // so that informations on the footbar are updated. (this should be better handled by + // so that informations on the footbar are updated. (this should be better handled by // promoting code in tm_editor::apply_changes (which is activated only after idle periods) // at the level of delayed commands in the gui. // The interval cannot be too small to keep CPU usage low in idle state -} +} @@ -253,29 +253,29 @@ qt_gui_rep::event_loop () { static hashmap<socket_notifier,pointer> read_notifiers; static hashmap<socket_notifier,pointer> write_notifiers; -void +void qt_gui_rep::add_notifier (socket_notifier sn) { QSocketNotifier *qsn; // cout << "ADD NOTIFIER" << LF; - + // replace any already present notifier remove_notifier (sn); // installs both a read and a write notifier (the texmacs interface does not specify enough its needs) - - read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, QSocketNotifier::Read, gui_helper)); + + read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, QSocketNotifier::Read, gui_helper)); QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, SLOT(doSocketNotification(int)) ); write_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, QSocketNotifier::Write, gui_helper)); - QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, SLOT(doSocketNotification(int)) ); + QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, SLOT(doSocketNotification(int)) ); } -void +void qt_gui_rep::remove_notifier (socket_notifier sn) -{ +{ QSocketNotifier *qsn; // cout << "REMOVE NOTIFIER" << LF; @@ -302,8 +302,8 @@ qt_gui_rep::remove_notifier (socket_notifier sn) * Delayed commands ******************************************************************************/ -QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) - : QObject (), cmd (_cmd), timer () +QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) + : QObject (), cmd (_cmd), timer () { QObject::connect (&timer, SIGNAL (timeout()), this, SLOT (doCommand())); timer.setSingleShot (true); @@ -316,7 +316,7 @@ QTMCommandHelper::doCommand() object obj= call (cmd); if (is_int (obj)) { timer.start (as_int (obj)); - } + } if (!(timer.isActive ())) deleteLater(); } @@ -347,14 +347,14 @@ void restart_global_timer (int pause = 0) { static array <object> delayed_commands; -void +void exec_delayed (object cmd) -{ +{ delayed_commands << cmd; restart_global_timer (); } -void +void exec_delayed_pause (object cmd) { delayed_commands << cmd; @@ -363,9 +363,9 @@ exec_delayed_pause (object cmd) void exec_pending_commands () { - // guarantee sequential execution of delayed commands + // guarantee sequential execution of delayed commands // otherwise some bugs appear in keyboard handling - + int i, n= N(delayed_commands); for (i=0; i<n; i++) { object obj= call (delayed_commands[i]); @@ -429,6 +429,12 @@ exec_pending_commands () { restart_global_timer (lapse); } } + +void +clear_pending_commands () { + delayed_queue= array<object> (0); + start_queue= array<int> (0); +} #endif /****************************************************************************** @@ -534,9 +540,9 @@ set_default_font (string name) { font get_default_font (bool tt) { - (void) tt; + (void) tt; // get the default font or monospaced font (if tt is true) - + // return a null font since this function is not called in the Qt port. if (DEBUG_EVENTS) cout << "get_default_font(): SHOULD NOT BE CALLED\n"; return NULL; diff --git a/src/src/Texmacs/Server/tm_server.cpp b/src/src/Texmacs/Server/tm_server.cpp index 7e3a671..2fc2968 100644 --- a/src/src/Texmacs/Server/tm_server.cpp +++ b/src/src/Texmacs/Server/tm_server.cpp @@ -295,7 +295,7 @@ void tm_server_rep::interpose_handler () { #ifdef QTTEXMACS // TeXmacs/Qt handles delayed messages and socket notification - // in its own runloop + // in its own runloop #else #if 0 // choice between old and new socket listening methods listen_to_servers (); @@ -428,6 +428,7 @@ void tm_server_rep::quit () { close_all_pipes (); call ("quit-TeXmacs-scheme"); + clear_pending_commands (); exit (0); } -- 1.6.3.3 From 45445c12ca72778458787b8a9acbe9371bfb3fc9 Mon Sep 17 00:00:00 2001 From: Norbert Nemec <Norbert@...> Date: Mon, 12 Oct 2009 18:07:28 +0100 Subject: [PATCH 2/2] Bugfix for delayed execution in Qt --- src/src/Plugins/Qt/qt_gui.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/qt_gui.cpp index 82be74a..bb7b33f 100755 --- a/src/src/Plugins/Qt/qt_gui.cpp +++ b/src/src/Plugins/Qt/qt_gui.cpp @@ -421,7 +421,7 @@ exec_pending_commands () { int lapse = start_queue[0]; int n = N(start_queue); for (i=1; i<n; i++) { - if (lapse < start_queue[i]) lapse = start_queue[i]; + if (start_queue[i] < lapse) lapse = start_queue[i]; } lapse = lapse - (int) texmacs_time (); if (lapse < 0) lapse = 0; -- 1.6.3.3 _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Massimiliano Gubinelli
::
Rate this Message:
Hi all, On 12 oct. 09, at 19:23, Norbert Nemec wrote: > Hi there, > > I identified two different problems with the delayed execution. One > is general, the other Qt-specific > > patch 0001: > I once had a segfault during exiting. Turned out that the "static > list<SCM> destroy_list" in Guile/Scheme/object.cpp was deleted > before the "static array<object> delayed_queue". If the latter still > contains objects (which happens once every blue moon) these are > added to the former, which does not exist any more. => CRASH. The > solution is a new function clear_pending_events which is called > before exit(0) in quit. Should be relevant for TeXmacs in general, > even though it might be an extremely rare event. > > patch 0002: > turns out that a trivial swap of a "<" caused the strange > sluggishness with the new delayed execution that I encountered. The > fix is just as trivial... > Both commited. Thanks. Are there still problems with the new runloop? I have some other patches to the menu caching mechanism but I want to be sure they do not superpose with unresolved bug introduced by recent modifications. Best, Massimiliano > Greetings, > Norbert > > > > From e75324a558b9eac3af802b3debaad797f560f90b Mon Sep 17 00:00:00 2001 > From: Norbert Nemec <Norbert@...> > Date: Mon, 12 Oct 2009 14:11:04 +0100 > Subject: [PATCH 1/2] Clear pending events before exiting. > > --- > src/src/Guile/Scheme/object.cpp | 7 +++ > src/src/Guile/Scheme/object.hpp | 1 + > src/src/Plugins/Qt/qt_gui.cpp | 72 +++++++++++++++++ > +--------------- > src/src/Texmacs/Server/tm_server.cpp | 3 +- > 4 files changed, 49 insertions(+), 34 deletions(-) > > diff --git a/src/src/Guile/Scheme/object.cpp b/src/src/Guile/Scheme/ > object.cpp > index b9a5369..ceb0530 100644 > --- a/src/src/Guile/Scheme/object.cpp > +++ b/src/src/Guile/Scheme/object.cpp > @@ -413,4 +413,11 @@ exec_pending_commands () { > } > } > } > + > +void > +clear_pending_commands () { > + delayed_queue= array<object> (0); > + start_queue= array<int> (0); > +} > + > #endif // QTTEXMACS > diff --git a/src/src/Guile/Scheme/object.hpp b/src/src/Guile/Scheme/ > object.hpp > index 0ed81c8..4be726b 100644 > --- a/src/src/Guile/Scheme/object.hpp > +++ b/src/src/Guile/Scheme/object.hpp > @@ -147,6 +147,7 @@ bool exec_file (url u); > void exec_delayed (object cmd); > void exec_delayed_pause (object cmd); > void exec_pending_commands (); > +void clear_pending_commands (); > > object call (const char* fun); > object call (const char* fun, object a1); > diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/ > qt_gui.cpp > index fd29e99..82be74a 100755 > --- a/src/src/Plugins/Qt/qt_gui.cpp > +++ b/src/src/Plugins/Qt/qt_gui.cpp > @@ -63,7 +63,7 @@ void > qt_gui_rep::get_extents (SI& width, SI& height) { > QDesktopWidget* d= QApplication::desktop(); > int w = d->width(); // returns desktop width > - int h = d->height(); // returns desktop height > + int h = d->height(); // returns desktop height > width = ((SI) w) * PIXEL; > height= ((SI) h) * PIXEL; > } > @@ -121,7 +121,7 @@ qt_gui_rep::get_selection (string key, tree& t, > string& s) { > } > s= ""; > t= "none"; > - > + > if (owns) { > if (selection_t->contains (key)) { > t= copy (selection_t [key]); > @@ -130,13 +130,13 @@ qt_gui_rep::get_selection (string key, tree& > t, string& s) { > } > return false; > } > - > + > QString originalText = cb->text(mode); > QByteArray buf = originalText.toAscii(); > if (!(buf.isEmpty())) { > s << string(buf.constData(), buf.size()); > } > - > + > t= tuple ("extern", s); > return true; > } > @@ -153,11 +153,11 @@ qt_gui_rep::set_selection (string key, tree t, > string s) { > //XSetSelectionOwner (dpy, XA_PRIMARY, win, CurrentTime); > //if (XGetSelectionOwner(dpy, XA_PRIMARY)==None) return false; > selection= as_charp (s); > - > + > QClipboard *clipboard = QApplication::clipboard(); > QString originalText = clipboard->text(); > - > - clipboard->setText(selection); > + > + clipboard->setText(selection); > } > return true; > } > @@ -218,23 +218,23 @@ void gui_interpose (void (*r) (void)) > { the_interpose_handler= r; } > > void > qt_gui_rep::update () { > - // this is called by doUpdate, which in turns is fired by a timer > activated in > + // this is called by doUpdate, which in turns is fired by a timer > activated in > // needs_update, and ensuring that interpose_handler is run during > a pass in the eventloop > - // afterwards we reactivate the timer with a pause (see FIXME > below) > - > + // afterwards we reactivate the timer with a pause (see FIXME > below) > + > if (the_interpose_handler) the_interpose_handler(); > - > + > qt_update_flag = false; > - interrupted = false; > - > + interrupted = false; > + > updatetimer->start (1000/6); > - > + > // FIXME: we need to ensure that the interpose_handler is run at > regular intervals (1/6th of sec) > - // so that informations on the footbar are updated. (this > should be better handled by > + // so that informations on the footbar are updated. (this > should be better handled by > // promoting code in tm_editor::apply_changes (which is > activated only after idle periods) > // at the level of delayed commands in the gui. > // The interval cannot be too small to keep CPU usage low > in idle state > -} > +} > > > > @@ -253,29 +253,29 @@ qt_gui_rep::event_loop () { > static hashmap<socket_notifier,pointer> read_notifiers; > static hashmap<socket_notifier,pointer> write_notifiers; > > -void > +void > qt_gui_rep::add_notifier (socket_notifier sn) > { > QSocketNotifier *qsn; > > // cout << "ADD NOTIFIER" << LF; > - > + > // replace any already present notifier > > remove_notifier (sn); > > // installs both a read and a write notifier (the texmacs > interface does not specify enough its needs) > - > - read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn- > >fd, QSocketNotifier::Read, gui_helper)); > + > + read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn- > >fd, QSocketNotifier::Read, gui_helper)); > QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, > SLOT(doSocketNotification(int)) ); > > write_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn- > >fd, QSocketNotifier::Write, gui_helper)); > - QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, > SLOT(doSocketNotification(int)) ); > + QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, > SLOT(doSocketNotification(int)) ); > } > > -void > +void > qt_gui_rep::remove_notifier (socket_notifier sn) > -{ > +{ > QSocketNotifier *qsn; > > // cout << "REMOVE NOTIFIER" << LF; > @@ -302,8 +302,8 @@ qt_gui_rep::remove_notifier (socket_notifier sn) > * Delayed commands > > ******************************************************************************/ > > -QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) > - : QObject (), cmd (_cmd), timer () > +QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) > + : QObject (), cmd (_cmd), timer () > { > QObject::connect (&timer, SIGNAL (timeout()), this, SLOT > (doCommand())); > timer.setSingleShot (true); > @@ -316,7 +316,7 @@ QTMCommandHelper::doCommand() > object obj= call (cmd); > if (is_int (obj)) { > timer.start (as_int (obj)); > - } > + } > if (!(timer.isActive ())) deleteLater(); > } > > @@ -347,14 +347,14 @@ void restart_global_timer (int pause = 0) { > > static array <object> delayed_commands; > > -void > +void > exec_delayed (object cmd) > -{ > +{ > delayed_commands << cmd; > restart_global_timer (); > } > > -void > +void > exec_delayed_pause (object cmd) > { > delayed_commands << cmd; > @@ -363,9 +363,9 @@ exec_delayed_pause (object cmd) > > void exec_pending_commands () > { > - // guarantee sequential execution of delayed commands > + // guarantee sequential execution of delayed commands > // otherwise some bugs appear in keyboard handling > - > + > int i, n= N(delayed_commands); > for (i=0; i<n; i++) { > object obj= call (delayed_commands[i]); > @@ -429,6 +429,12 @@ exec_pending_commands () { > restart_global_timer (lapse); > } > } > + > +void > +clear_pending_commands () { > + delayed_queue= array<object> (0); > + start_queue= array<int> (0); > +} > #endif > > / > ****************************************************************************** > @@ -534,9 +540,9 @@ set_default_font (string name) { > > font > get_default_font (bool tt) { > - (void) tt; > + (void) tt; > // get the default font or monospaced font (if tt is true) > - > + > // return a null font since this function is not called in the Qt > port. > if (DEBUG_EVENTS) cout << "get_default_font(): SHOULD NOT BE CALLED > \n"; > return NULL; > diff --git a/src/src/Texmacs/Server/tm_server.cpp b/src/src/Texmacs/ > Server/tm_server.cpp > index 7e3a671..2fc2968 100644 > --- a/src/src/Texmacs/Server/tm_server.cpp > +++ b/src/src/Texmacs/Server/tm_server.cpp > @@ -295,7 +295,7 @@ void > tm_server_rep::interpose_handler () { > #ifdef QTTEXMACS > // TeXmacs/Qt handles delayed messages and socket notification > - // in its own runloop > + // in its own runloop > #else > #if 0 // choice between old and new socket listening methods > listen_to_servers (); > @@ -428,6 +428,7 @@ void > tm_server_rep::quit () { > close_all_pipes (); > call ("quit-TeXmacs-scheme"); > + clear_pending_commands (); > exit (0); > } > > -- > 1.6.3.3 > > From 45445c12ca72778458787b8a9acbe9371bfb3fc9 Mon Sep 17 00:00:00 2001 > From: Norbert Nemec <Norbert@...> > Date: Mon, 12 Oct 2009 18:07:28 +0100 > Subject: [PATCH 2/2] Bugfix for delayed execution in Qt > > --- > src/src/Plugins/Qt/qt_gui.cpp | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/ > qt_gui.cpp > index 82be74a..bb7b33f 100755 > --- a/src/src/Plugins/Qt/qt_gui.cpp > +++ b/src/src/Plugins/Qt/qt_gui.cpp > @@ -421,7 +421,7 @@ exec_pending_commands () { > int lapse = start_queue[0]; > int n = N(start_queue); > for (i=1; i<n; i++) { > - if (lapse < start_queue[i]) lapse = start_queue[i]; > + if (start_queue[i] < lapse) lapse = start_queue[i]; > } > lapse = lapse - (int) texmacs_time (); > if (lapse < 0) lapse = 0; > -- > 1.6.3.3 > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... > http://lists.gnu.org/mailman/listinfo/texmacs-dev _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Álvaro Tejero Cantero
::
Rate this Message:
I didn't notice any problems, but TeXmacs-QT feels slower already when
typing at the end of 3-line paragraphs. Is there any more quantitative way to test performance? When I click on tools>timing, nothing happens for either version. -á. On Tue, Oct 13, 2009 at 10:50, Gubinelli Massimiliano <m.gubinelli@...> wrote: > > Hi all, > > On 12 oct. 09, at 19:23, Norbert Nemec wrote: > >> Hi there, >> >> I identified two different problems with the delayed execution. One is >> general, the other Qt-specific >> >> patch 0001: >> I once had a segfault during exiting. Turned out that the "static >> list<SCM> destroy_list" in Guile/Scheme/object.cpp was deleted before the >> "static array<object> delayed_queue". If the latter still contains objects >> (which happens once every blue moon) these are added to the former, which >> does not exist any more. => CRASH. The solution is a new function >> clear_pending_events which is called before exit(0) in quit. Should be >> relevant for TeXmacs in general, even though it might be an extremely rare >> event. >> >> patch 0002: >> turns out that a trivial swap of a "<" caused the strange sluggishness >> with the new delayed execution that I encountered. The fix is just as >> trivial... >> > > Both commited. Thanks. Are there still problems with the new runloop? I have > some other patches to the menu caching mechanism but I want to be sure they > do not superpose with unresolved bug introduced by recent modifications. > > Best, > > Massimiliano > > > >> Greetings, >> Norbert >> >> >> >> From e75324a558b9eac3af802b3debaad797f560f90b Mon Sep 17 00:00:00 2001 >> From: Norbert Nemec <Norbert@...> >> Date: Mon, 12 Oct 2009 14:11:04 +0100 >> Subject: [PATCH 1/2] Clear pending events before exiting. >> >> --- >> src/src/Guile/Scheme/object.cpp | 7 +++ >> src/src/Guile/Scheme/object.hpp | 1 + >> src/src/Plugins/Qt/qt_gui.cpp | 72 >> ++++++++++++++++++--------------- >> src/src/Texmacs/Server/tm_server.cpp | 3 +- >> 4 files changed, 49 insertions(+), 34 deletions(-) >> >> diff --git a/src/src/Guile/Scheme/object.cpp >> b/src/src/Guile/Scheme/object.cpp >> index b9a5369..ceb0530 100644 >> --- a/src/src/Guile/Scheme/object.cpp >> +++ b/src/src/Guile/Scheme/object.cpp >> @@ -413,4 +413,11 @@ exec_pending_commands () { >> } >> } >> } >> + >> +void >> +clear_pending_commands () { >> + delayed_queue= array<object> (0); >> + start_queue= array<int> (0); >> +} >> + >> #endif // QTTEXMACS >> diff --git a/src/src/Guile/Scheme/object.hpp >> b/src/src/Guile/Scheme/object.hpp >> index 0ed81c8..4be726b 100644 >> --- a/src/src/Guile/Scheme/object.hpp >> +++ b/src/src/Guile/Scheme/object.hpp >> @@ -147,6 +147,7 @@ bool exec_file (url u); >> void exec_delayed (object cmd); >> void exec_delayed_pause (object cmd); >> void exec_pending_commands (); >> +void clear_pending_commands (); >> >> object call (const char* fun); >> object call (const char* fun, object a1); >> diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/qt_gui.cpp >> index fd29e99..82be74a 100755 >> --- a/src/src/Plugins/Qt/qt_gui.cpp >> +++ b/src/src/Plugins/Qt/qt_gui.cpp >> @@ -63,7 +63,7 @@ void >> qt_gui_rep::get_extents (SI& width, SI& height) { >> QDesktopWidget* d= QApplication::desktop(); >> int w = d->width(); // returns desktop width >> - int h = d->height(); // returns desktop height >> + int h = d->height(); // returns desktop height >> width = ((SI) w) * PIXEL; >> height= ((SI) h) * PIXEL; >> } >> @@ -121,7 +121,7 @@ qt_gui_rep::get_selection (string key, tree& t, >> string& s) { >> } >> s= ""; >> t= "none"; >> - >> + >> if (owns) { >> if (selection_t->contains (key)) { >> t= copy (selection_t [key]); >> @@ -130,13 +130,13 @@ qt_gui_rep::get_selection (string key, tree& t, >> string& s) { >> } >> return false; >> } >> - >> + >> QString originalText = cb->text(mode); >> QByteArray buf = originalText.toAscii(); >> if (!(buf.isEmpty())) { >> s << string(buf.constData(), buf.size()); >> } >> - >> + >> t= tuple ("extern", s); >> return true; >> } >> @@ -153,11 +153,11 @@ qt_gui_rep::set_selection (string key, tree t, >> string s) { >> //XSetSelectionOwner (dpy, XA_PRIMARY, win, CurrentTime); >> //if (XGetSelectionOwner(dpy, XA_PRIMARY)==None) return false; >> selection= as_charp (s); >> - >> + >> QClipboard *clipboard = QApplication::clipboard(); >> QString originalText = clipboard->text(); >> - >> - clipboard->setText(selection); >> + >> + clipboard->setText(selection); >> } >> return true; >> } >> @@ -218,23 +218,23 @@ void gui_interpose (void (*r) (void)) { >> the_interpose_handler= r; } >> >> void >> qt_gui_rep::update () { >> - // this is called by doUpdate, which in turns is fired by a timer >> activated in >> + // this is called by doUpdate, which in turns is fired by a timer >> activated in >> // needs_update, and ensuring that interpose_handler is run during a pass >> in the eventloop >> - // afterwards we reactivate the timer with a pause (see FIXME below) >> - >> + // afterwards we reactivate the timer with a pause (see FIXME below) >> + >> if (the_interpose_handler) the_interpose_handler(); >> - >> + >> qt_update_flag = false; >> - interrupted = false; >> - >> + interrupted = false; >> + >> updatetimer->start (1000/6); >> - >> + >> // FIXME: we need to ensure that the interpose_handler is run at regular >> intervals (1/6th of sec) >> - // so that informations on the footbar are updated. (this should >> be better handled by >> + // so that informations on the footbar are updated. (this should >> be better handled by >> // promoting code in tm_editor::apply_changes (which is activated >> only after idle periods) >> // at the level of delayed commands in the gui. >> // The interval cannot be too small to keep CPU usage low in idle >> state >> -} >> +} >> >> >> >> @@ -253,29 +253,29 @@ qt_gui_rep::event_loop () { >> static hashmap<socket_notifier,pointer> read_notifiers; >> static hashmap<socket_notifier,pointer> write_notifiers; >> >> -void >> +void >> qt_gui_rep::add_notifier (socket_notifier sn) >> { >> QSocketNotifier *qsn; >> >> // cout << "ADD NOTIFIER" << LF; >> - >> + >> // replace any already present notifier >> >> remove_notifier (sn); >> >> // installs both a read and a write notifier (the texmacs interface does >> not specify enough its needs) >> - >> - read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, >> QSocketNotifier::Read, gui_helper)); >> + >> + read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, >> QSocketNotifier::Read, gui_helper)); >> QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, >> SLOT(doSocketNotification(int)) ); >> >> write_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, >> QSocketNotifier::Write, gui_helper)); >> - QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, >> SLOT(doSocketNotification(int)) ); >> + QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, >> SLOT(doSocketNotification(int)) ); >> } >> >> -void >> +void >> qt_gui_rep::remove_notifier (socket_notifier sn) >> -{ >> +{ >> QSocketNotifier *qsn; >> >> // cout << "REMOVE NOTIFIER" << LF; >> @@ -302,8 +302,8 @@ qt_gui_rep::remove_notifier (socket_notifier sn) >> * Delayed commands >> >> ******************************************************************************/ >> >> -QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) >> - : QObject (), cmd (_cmd), timer () >> +QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) >> + : QObject (), cmd (_cmd), timer () >> { >> QObject::connect (&timer, SIGNAL (timeout()), this, SLOT (doCommand())); >> timer.setSingleShot (true); >> @@ -316,7 +316,7 @@ QTMCommandHelper::doCommand() >> object obj= call (cmd); >> if (is_int (obj)) { >> timer.start (as_int (obj)); >> - } >> + } >> if (!(timer.isActive ())) deleteLater(); >> } >> >> @@ -347,14 +347,14 @@ void restart_global_timer (int pause = 0) { >> >> static array <object> delayed_commands; >> >> -void >> +void >> exec_delayed (object cmd) >> -{ >> +{ >> delayed_commands << cmd; >> restart_global_timer (); >> } >> >> -void >> +void >> exec_delayed_pause (object cmd) >> { >> delayed_commands << cmd; >> @@ -363,9 +363,9 @@ exec_delayed_pause (object cmd) >> >> void exec_pending_commands () >> { >> - // guarantee sequential execution of delayed commands >> + // guarantee sequential execution of delayed commands >> // otherwise some bugs appear in keyboard handling >> - >> + >> int i, n= N(delayed_commands); >> for (i=0; i<n; i++) { >> object obj= call (delayed_commands[i]); >> @@ -429,6 +429,12 @@ exec_pending_commands () { >> restart_global_timer (lapse); >> } >> } >> + >> +void >> +clear_pending_commands () { >> + delayed_queue= array<object> (0); >> + start_queue= array<int> (0); >> +} >> #endif >> >> >> /****************************************************************************** >> @@ -534,9 +540,9 @@ set_default_font (string name) { >> >> font >> get_default_font (bool tt) { >> - (void) tt; >> + (void) tt; >> // get the default font or monospaced font (if tt is true) >> - >> + >> // return a null font since this function is not called in the Qt port. >> if (DEBUG_EVENTS) cout << "get_default_font(): SHOULD NOT BE CALLED\n"; >> return NULL; >> diff --git a/src/src/Texmacs/Server/tm_server.cpp >> b/src/src/Texmacs/Server/tm_server.cpp >> index 7e3a671..2fc2968 100644 >> --- a/src/src/Texmacs/Server/tm_server.cpp >> +++ b/src/src/Texmacs/Server/tm_server.cpp >> @@ -295,7 +295,7 @@ void >> tm_server_rep::interpose_handler () { >> #ifdef QTTEXMACS >> // TeXmacs/Qt handles delayed messages and socket notification >> - // in its own runloop >> + // in its own runloop >> #else >> #if 0 // choice between old and new socket listening methods >> listen_to_servers (); >> @@ -428,6 +428,7 @@ void >> tm_server_rep::quit () { >> close_all_pipes (); >> call ("quit-TeXmacs-scheme"); >> + clear_pending_commands (); >> exit (0); >> } >> >> -- >> 1.6.3.3 >> >> From 45445c12ca72778458787b8a9acbe9371bfb3fc9 Mon Sep 17 00:00:00 2001 >> From: Norbert Nemec <Norbert@...> >> Date: Mon, 12 Oct 2009 18:07:28 +0100 >> Subject: [PATCH 2/2] Bugfix for delayed execution in Qt >> >> --- >> src/src/Plugins/Qt/qt_gui.cpp | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/qt_gui.cpp >> index 82be74a..bb7b33f 100755 >> --- a/src/src/Plugins/Qt/qt_gui.cpp >> +++ b/src/src/Plugins/Qt/qt_gui.cpp >> @@ -421,7 +421,7 @@ exec_pending_commands () { >> int lapse = start_queue[0]; >> int n = N(start_queue); >> for (i=1; i<n; i++) { >> - if (lapse < start_queue[i]) lapse = start_queue[i]; >> + if (start_queue[i] < lapse) lapse = start_queue[i]; >> } >> lapse = lapse - (int) texmacs_time (); >> if (lapse < 0) lapse = 0; >> -- >> 1.6.3.3 >> >> _______________________________________________ >> Texmacs-dev mailing list >> Texmacs-dev@... >> http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... > http://lists.gnu.org/mailman/listinfo/texmacs-dev > _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Álvaro Tejero Cantero
::
Rate this Message:
Actually, the standard X11 protocol copy-on-selection doesn't work.
-á. On Tue, Oct 13, 2009 at 17:14, Álvaro Tejero Cantero <alvarot@...> wrote: > I didn't notice any problems, but TeXmacs-QT feels slower already when > typing at the end of 3-line paragraphs. Is there any more quantitative > way to test performance? When I click on tools>timing, nothing happens > for either version. > > -á. > > > > On Tue, Oct 13, 2009 at 10:50, Gubinelli Massimiliano > <m.gubinelli@...> wrote: >> >> Hi all, >> >> On 12 oct. 09, at 19:23, Norbert Nemec wrote: >> >>> Hi there, >>> >>> I identified two different problems with the delayed execution. One is >>> general, the other Qt-specific >>> >>> patch 0001: >>> I once had a segfault during exiting. Turned out that the "static >>> list<SCM> destroy_list" in Guile/Scheme/object.cpp was deleted before the >>> "static array<object> delayed_queue". If the latter still contains objects >>> (which happens once every blue moon) these are added to the former, which >>> does not exist any more. => CRASH. The solution is a new function >>> clear_pending_events which is called before exit(0) in quit. Should be >>> relevant for TeXmacs in general, even though it might be an extremely rare >>> event. >>> >>> patch 0002: >>> turns out that a trivial swap of a "<" caused the strange sluggishness >>> with the new delayed execution that I encountered. The fix is just as >>> trivial... >>> >> >> Both commited. Thanks. Are there still problems with the new runloop? I have >> some other patches to the menu caching mechanism but I want to be sure they >> do not superpose with unresolved bug introduced by recent modifications. >> >> Best, >> >> Massimiliano >> >> >> >>> Greetings, >>> Norbert >>> >>> >>> >>> From e75324a558b9eac3af802b3debaad797f560f90b Mon Sep 17 00:00:00 2001 >>> From: Norbert Nemec <Norbert@...> >>> Date: Mon, 12 Oct 2009 14:11:04 +0100 >>> Subject: [PATCH 1/2] Clear pending events before exiting. >>> >>> --- >>> src/src/Guile/Scheme/object.cpp | 7 +++ >>> src/src/Guile/Scheme/object.hpp | 1 + >>> src/src/Plugins/Qt/qt_gui.cpp | 72 >>> ++++++++++++++++++--------------- >>> src/src/Texmacs/Server/tm_server.cpp | 3 +- >>> 4 files changed, 49 insertions(+), 34 deletions(-) >>> >>> diff --git a/src/src/Guile/Scheme/object.cpp >>> b/src/src/Guile/Scheme/object.cpp >>> index b9a5369..ceb0530 100644 >>> --- a/src/src/Guile/Scheme/object.cpp >>> +++ b/src/src/Guile/Scheme/object.cpp >>> @@ -413,4 +413,11 @@ exec_pending_commands () { >>> } >>> } >>> } >>> + >>> +void >>> +clear_pending_commands () { >>> + delayed_queue= array<object> (0); >>> + start_queue= array<int> (0); >>> +} >>> + >>> #endif // QTTEXMACS >>> diff --git a/src/src/Guile/Scheme/object.hpp >>> b/src/src/Guile/Scheme/object.hpp >>> index 0ed81c8..4be726b 100644 >>> --- a/src/src/Guile/Scheme/object.hpp >>> +++ b/src/src/Guile/Scheme/object.hpp >>> @@ -147,6 +147,7 @@ bool exec_file (url u); >>> void exec_delayed (object cmd); >>> void exec_delayed_pause (object cmd); >>> void exec_pending_commands (); >>> +void clear_pending_commands (); >>> >>> object call (const char* fun); >>> object call (const char* fun, object a1); >>> diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/qt_gui.cpp >>> index fd29e99..82be74a 100755 >>> --- a/src/src/Plugins/Qt/qt_gui.cpp >>> +++ b/src/src/Plugins/Qt/qt_gui.cpp >>> @@ -63,7 +63,7 @@ void >>> qt_gui_rep::get_extents (SI& width, SI& height) { >>> QDesktopWidget* d= QApplication::desktop(); >>> int w = d->width(); // returns desktop width >>> - int h = d->height(); // returns desktop height >>> + int h = d->height(); // returns desktop height >>> width = ((SI) w) * PIXEL; >>> height= ((SI) h) * PIXEL; >>> } >>> @@ -121,7 +121,7 @@ qt_gui_rep::get_selection (string key, tree& t, >>> string& s) { >>> } >>> s= ""; >>> t= "none"; >>> - >>> + >>> if (owns) { >>> if (selection_t->contains (key)) { >>> t= copy (selection_t [key]); >>> @@ -130,13 +130,13 @@ qt_gui_rep::get_selection (string key, tree& t, >>> string& s) { >>> } >>> return false; >>> } >>> - >>> + >>> QString originalText = cb->text(mode); >>> QByteArray buf = originalText.toAscii(); >>> if (!(buf.isEmpty())) { >>> s << string(buf.constData(), buf.size()); >>> } >>> - >>> + >>> t= tuple ("extern", s); >>> return true; >>> } >>> @@ -153,11 +153,11 @@ qt_gui_rep::set_selection (string key, tree t, >>> string s) { >>> //XSetSelectionOwner (dpy, XA_PRIMARY, win, CurrentTime); >>> //if (XGetSelectionOwner(dpy, XA_PRIMARY)==None) return false; >>> selection= as_charp (s); >>> - >>> + >>> QClipboard *clipboard = QApplication::clipboard(); >>> QString originalText = clipboard->text(); >>> - >>> - clipboard->setText(selection); >>> + >>> + clipboard->setText(selection); >>> } >>> return true; >>> } >>> @@ -218,23 +218,23 @@ void gui_interpose (void (*r) (void)) { >>> the_interpose_handler= r; } >>> >>> void >>> qt_gui_rep::update () { >>> - // this is called by doUpdate, which in turns is fired by a timer >>> activated in >>> + // this is called by doUpdate, which in turns is fired by a timer >>> activated in >>> // needs_update, and ensuring that interpose_handler is run during a pass >>> in the eventloop >>> - // afterwards we reactivate the timer with a pause (see FIXME below) >>> - >>> + // afterwards we reactivate the timer with a pause (see FIXME below) >>> + >>> if (the_interpose_handler) the_interpose_handler(); >>> - >>> + >>> qt_update_flag = false; >>> - interrupted = false; >>> - >>> + interrupted = false; >>> + >>> updatetimer->start (1000/6); >>> - >>> + >>> // FIXME: we need to ensure that the interpose_handler is run at regular >>> intervals (1/6th of sec) >>> - // so that informations on the footbar are updated. (this should >>> be better handled by >>> + // so that informations on the footbar are updated. (this should >>> be better handled by >>> // promoting code in tm_editor::apply_changes (which is activated >>> only after idle periods) >>> // at the level of delayed commands in the gui. >>> // The interval cannot be too small to keep CPU usage low in idle >>> state >>> -} >>> +} >>> >>> >>> >>> @@ -253,29 +253,29 @@ qt_gui_rep::event_loop () { >>> static hashmap<socket_notifier,pointer> read_notifiers; >>> static hashmap<socket_notifier,pointer> write_notifiers; >>> >>> -void >>> +void >>> qt_gui_rep::add_notifier (socket_notifier sn) >>> { >>> QSocketNotifier *qsn; >>> >>> // cout << "ADD NOTIFIER" << LF; >>> - >>> + >>> // replace any already present notifier >>> >>> remove_notifier (sn); >>> >>> // installs both a read and a write notifier (the texmacs interface does >>> not specify enough its needs) >>> - >>> - read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, >>> QSocketNotifier::Read, gui_helper)); >>> + >>> + read_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, >>> QSocketNotifier::Read, gui_helper)); >>> QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, >>> SLOT(doSocketNotification(int)) ); >>> >>> write_notifiers (sn) = (pointer) (qsn = new QSocketNotifier(sn->fd, >>> QSocketNotifier::Write, gui_helper)); >>> - QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, >>> SLOT(doSocketNotification(int)) ); >>> + QObject::connect(qsn, SIGNAL(activated(int)), gui_helper, >>> SLOT(doSocketNotification(int)) ); >>> } >>> >>> -void >>> +void >>> qt_gui_rep::remove_notifier (socket_notifier sn) >>> -{ >>> +{ >>> QSocketNotifier *qsn; >>> >>> // cout << "REMOVE NOTIFIER" << LF; >>> @@ -302,8 +302,8 @@ qt_gui_rep::remove_notifier (socket_notifier sn) >>> * Delayed commands >>> >>> ******************************************************************************/ >>> >>> -QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) >>> - : QObject (), cmd (_cmd), timer () >>> +QTMCommandHelper::QTMCommandHelper (object _cmd, int delay = 0) >>> + : QObject (), cmd (_cmd), timer () >>> { >>> QObject::connect (&timer, SIGNAL (timeout()), this, SLOT (doCommand())); >>> timer.setSingleShot (true); >>> @@ -316,7 +316,7 @@ QTMCommandHelper::doCommand() >>> object obj= call (cmd); >>> if (is_int (obj)) { >>> timer.start (as_int (obj)); >>> - } >>> + } >>> if (!(timer.isActive ())) deleteLater(); >>> } >>> >>> @@ -347,14 +347,14 @@ void restart_global_timer (int pause = 0) { >>> >>> static array <object> delayed_commands; >>> >>> -void >>> +void >>> exec_delayed (object cmd) >>> -{ >>> +{ >>> delayed_commands << cmd; >>> restart_global_timer (); >>> } >>> >>> -void >>> +void >>> exec_delayed_pause (object cmd) >>> { >>> delayed_commands << cmd; >>> @@ -363,9 +363,9 @@ exec_delayed_pause (object cmd) >>> >>> void exec_pending_commands () >>> { >>> - // guarantee sequential execution of delayed commands >>> + // guarantee sequential execution of delayed commands >>> // otherwise some bugs appear in keyboard handling >>> - >>> + >>> int i, n= N(delayed_commands); >>> for (i=0; i<n; i++) { >>> object obj= call (delayed_commands[i]); >>> @@ -429,6 +429,12 @@ exec_pending_commands () { >>> restart_global_timer (lapse); >>> } >>> } >>> + >>> +void >>> +clear_pending_commands () { >>> + delayed_queue= array<object> (0); >>> + start_queue= array<int> (0); >>> +} >>> #endif >>> >>> >>> /****************************************************************************** >>> @@ -534,9 +540,9 @@ set_default_font (string name) { >>> >>> font >>> get_default_font (bool tt) { >>> - (void) tt; >>> + (void) tt; >>> // get the default font or monospaced font (if tt is true) >>> - >>> + >>> // return a null font since this function is not called in the Qt port. >>> if (DEBUG_EVENTS) cout << "get_default_font(): SHOULD NOT BE CALLED\n"; >>> return NULL; >>> diff --git a/src/src/Texmacs/Server/tm_server.cpp >>> b/src/src/Texmacs/Server/tm_server.cpp >>> index 7e3a671..2fc2968 100644 >>> --- a/src/src/Texmacs/Server/tm_server.cpp >>> +++ b/src/src/Texmacs/Server/tm_server.cpp >>> @@ -295,7 +295,7 @@ void >>> tm_server_rep::interpose_handler () { >>> #ifdef QTTEXMACS >>> // TeXmacs/Qt handles delayed messages and socket notification >>> - // in its own runloop >>> + // in its own runloop >>> #else >>> #if 0 // choice between old and new socket listening methods >>> listen_to_servers (); >>> @@ -428,6 +428,7 @@ void >>> tm_server_rep::quit () { >>> close_all_pipes (); >>> call ("quit-TeXmacs-scheme"); >>> + clear_pending_commands (); >>> exit (0); >>> } >>> >>> -- >>> 1.6.3.3 >>> >>> From 45445c12ca72778458787b8a9acbe9371bfb3fc9 Mon Sep 17 00:00:00 2001 >>> From: Norbert Nemec <Norbert@...> >>> Date: Mon, 12 Oct 2009 18:07:28 +0100 >>> Subject: [PATCH 2/2] Bugfix for delayed execution in Qt >>> >>> --- >>> src/src/Plugins/Qt/qt_gui.cpp | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/src/src/Plugins/Qt/qt_gui.cpp b/src/src/Plugins/Qt/qt_gui.cpp >>> index 82be74a..bb7b33f 100755 >>> --- a/src/src/Plugins/Qt/qt_gui.cpp >>> +++ b/src/src/Plugins/Qt/qt_gui.cpp >>> @@ -421,7 +421,7 @@ exec_pending_commands () { >>> int lapse = start_queue[0]; >>> int n = N(start_queue); >>> for (i=1; i<n; i++) { >>> - if (lapse < start_queue[i]) lapse = start_queue[i]; >>> + if (start_queue[i] < lapse) lapse = start_queue[i]; >>> } >>> lapse = lapse - (int) texmacs_time (); >>> if (lapse < 0) lapse = 0; >>> -- >>> 1.6.3.3 >>> >>> _______________________________________________ >>> Texmacs-dev mailing list >>> Texmacs-dev@... >>> http://lists.gnu.org/mailman/listinfo/texmacs-dev >> >> >> >> _______________________________________________ >> Texmacs-dev mailing list >> Texmacs-dev@... >> http://lists.gnu.org/mailman/listinfo/texmacs-dev >> > _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Joris van der Hoeven
::
Rate this Message:
On Tue, Oct 13, 2009 at 05:14:02PM +0200, Álvaro Tejero Cantero wrote:
> I didn't notice any problems, but TeXmacs-QT feels slower already when > typing at the end of 3-line paragraphs. That is shortcoming of the current Qt version: interrupts during the rendering phase have not yet been implemented. Now that delayed_event has become cleaner, maybe Max can fix that one too. > Is there any more quantitative way to test performance? This is rather a matter of reactivity. Hard to measure. Best wishes, --Joris _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Mouse copy-on-select (was: Two fixes for delayed execution)
by Norbert Nemec
::
Rate this Message:
Álvaro Tejero Cantero wrote:
> Actually, the standard X11 protocol copy-on-selection doesn't work. > Indeed, I can reproduce the problem. I will look at it. _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Norbert Nemec
::
Rate this Message:
In fact, I found a clear measurement that indicates a problem:
Running TeXmacs/Qt on my fairly modern notebook (fully optimized compile). I fill one page with plain text. Now simply moving through the text with the right arrow (no editing!) brings up the CPU load to 100%. Of this, 95% are spent in the X server. TeXmacs itself only takes 5% of the CPU power. I tried activating the code in check_event. The display is incomplete now, but the CPU load is down to 30% and TeXmacs feels fully reactive. Seems like this optimization is crucial not only for slow machines after all... Greetings, Norbert Joris van der Hoeven wrote: > On Tue, Oct 13, 2009 at 05:14:02PM +0200, Álvaro Tejero Cantero wrote: > >> I didn't notice any problems, but TeXmacs-QT feels slower already when >> typing at the end of 3-line paragraphs. >> > > That is shortcoming of the current Qt version: > interrupts during the rendering phase have not yet been implemented. > Now that delayed_event has become cleaner, maybe Max can fix that one too. > > >> Is there any more quantitative way to test performance? >> > > This is rather a matter of reactivity. Hard to measure. > > Best wishes, --Joris > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Massimiliano Gubinelli
::
Rate this Message:
Hi,
On 13 oct. 09, at 22:32, Norbert Nemec wrote: > In fact, I found a clear measurement that indicates a problem: > > Running TeXmacs/Qt on my fairly modern notebook (fully optimized > compile). > > I fill one page with plain text. Now simply moving through the text > with the right arrow (no editing!) brings up the CPU load to 100%. > Of this, 95% are spent in the X server. TeXmacs itself only takes 5% > of the CPU power. > I can confirm this observation. In my ubuntu virtual machine (VirtualBox/MacOSX) the above protocol gives \sim 75% CPU load to Xorg and \sim 23% to texmacs. You should check that you do not use cairo since at the moment the cairo rendering is slightly unoptimal in QT (explicit and naive double-buffer). On my mac the load remains reasonable (30% which should include the GUI load also since the total CPU load is not much higher). Proprer implementation of check_event require knowing if there are pending key events in the queue and this is not possible in Qt (or even in Cocoa). Moderns GUI API explicitly discurage looking at the event queue so we should design a different mechanism to reimplement what it is currently done in the X11 port. best max > I tried activating the code in check_event. The display is > incomplete now, but the CPU load is down to 30% and TeXmacs feels > fully reactive. > > Seems like this optimization is crucial not only for slow machines > after all... > > Greetings, > Norbert > > > > > Joris van der Hoeven wrote: >> On Tue, Oct 13, 2009 at 05:14:02PM +0200, Álvaro Tejero Cantero >> wrote: >> >>> I didn't notice any problems, but TeXmacs-QT feels slower already >>> when >>> typing at the end of 3-line paragraphs. >>> >> >> That is shortcoming of the current Qt version: >> interrupts during the rendering phase have not yet been implemented. >> Now that delayed_event has become cleaner, maybe Max can fix that >> one too. >> >> >>> Is there any more quantitative way to test performance? >>> >> >> This is rather a matter of reactivity. Hard to measure. >> >> Best wishes, --Joris >> >> >> _______________________________________________ >> Texmacs-dev mailing list >> Texmacs-dev@... >> http://lists.gnu.org/mailman/listinfo/texmacs-dev >> >> > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... > http://lists.gnu.org/mailman/listinfo/texmacs-dev _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Alex D-3
::
Rate this Message:
Hi,
In case anyone is runing the Qt port on Intel graphics hardware on Ubuntu or similar systems and experiencing sluggish performance, a suggestion is to run the application with the '-graphicssystem raster' switch enabled. This yields greatly improved performance in my case. --Alex Dobkin On Wed, Oct 14, 2009 at 5:04 AM, Gubinelli Massimiliano <m.gubinelli@...> wrote: Hi, _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Norbert Nemec
::
Rate this Message:
Wow, indeed! X server load goes down to 30% when I move through a long
text. Sluggishness is completely gone... What does that switch do? Could it be set permanently? Does it affect only Intel graphics hardware? Greetings, Norbert Alex D wrote: > Hi, > > In case anyone is runing the Qt port on Intel graphics hardware on > Ubuntu or similar systems and experiencing sluggish performance, a > suggestion is to run the application with the '-graphicssystem raster' > switch enabled. This yields greatly improved performance in my case. > > --Alex Dobkin > > On Wed, Oct 14, 2009 at 5:04 AM, Gubinelli Massimiliano > <m.gubinelli@... <mailto:m.gubinelli@...>> wrote: > > Hi, > > > On 13 oct. 09, at 22:32, Norbert Nemec wrote: > > In fact, I found a clear measurement that indicates a problem: > > Running TeXmacs/Qt on my fairly modern notebook (fully > optimized compile). > > I fill one page with plain text. Now simply moving through the > text with the right arrow (no editing!) brings up the CPU load > to 100%. Of this, 95% are spent in the X server. TeXmacs > itself only takes 5% of the CPU power. > > > I can confirm this observation. In my ubuntu virtual machine > (VirtualBox/MacOSX) the above protocol gives \sim 75% CPU load to > Xorg and \sim 23% to texmacs. You should check that you do not use > cairo since at the moment the cairo rendering is slightly > unoptimal in QT (explicit and naive double-buffer). > On my mac the load remains reasonable (30% which should include > the GUI load also since the total CPU load is not much higher). > > Proprer implementation of check_event require knowing if there are > pending key events in the queue and this is not possible in Qt (or > even in Cocoa). Moderns GUI API explicitly discurage looking at > the event queue so we should design a different mechanism to > reimplement what it is currently done in the X11 port. > > > best > max > > > > I tried activating the code in check_event. The display is > incomplete now, but the CPU load is down to 30% and TeXmacs > feels fully reactive. > > > Seems like this optimization is crucial not only for slow > machines after all... > > > > > > Greetings, > Norbert > > > > > Joris van der Hoeven wrote: > > On Tue, Oct 13, 2009 at 05:14:02PM +0200, Álvaro Tejero > Cantero wrote: > > I didn't notice any problems, but TeXmacs-QT feels > slower already when > typing at the end of 3-line paragraphs. > > > That is shortcoming of the current Qt version: > interrupts during the rendering phase have not yet been > implemented. > Now that delayed_event has become cleaner, maybe Max can > fix that one too. > > > Is there any more quantitative way to test performance? > > > This is rather a matter of reactivity. Hard to measure. > > Best wishes, --Joris > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... > http://lists.gnu.org/mailman/listinfo/texmacs-dev > _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Norbert Nemec
::
Rate this Message:
Gubinelli Massimiliano wrote:
> Proprer implementation of check_event require knowing if there are > pending key events in the queue and this is not possible in Qt (or > even in Cocoa). Moderns GUI API explicitly discurage looking at the > event queue so we should design a different mechanism to reimplement > what it is currently done in the X11 port. Indeed. I guess a proper approach on Qt would be to use processEvents frequently during drawing. This does not work with the check_event gui interface, but the necessary change in the interface should be minimal. _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Alex D-3
::
Rate this Message:
If I understand correctly, the -graphicssystem raster switch tells the Qt library to use a different graphics backend that performs rendering and text rasterization in software (on the client) instead of relying on the server (X11).
I heard that these performance issues were due to performance regressions recently introduced into the Intel graphics drivers. However, the upcoming version of Ubuntu, Karmic Koala, introduces newer drivers which are supposed to fix all these issues. I'll do some testing when it comes out later this month. Setting the switch is the only way to force graphicssystem raster for a particular application short of recompiling the libraries. This can be done with a wrapper script. --Alex Dobkin
On Wed, Oct 14, 2009 at 11:19 AM, Norbert Nemec <Norbert.Nemec.list@...> wrote: Wow, indeed! X server load goes down to 30% when I move through a long text. Sluggishness is completely gone... _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Joris van der Hoeven
::
Rate this Message:
On Wed, Oct 14, 2009 at 05:27:03PM +0100, Norbert Nemec wrote:
> Gubinelli Massimiliano wrote: > >Proprer implementation of check_event require knowing if there are > >pending key events in the queue and this is not possible in Qt (or > >even in Cocoa). Moderns GUI API explicitly discurage looking at the > >event queue so we should design a different mechanism to reimplement > >what it is currently done in the X11 port. > > Indeed. I guess a proper approach on Qt would be to use processEvents > frequently during drawing. This does not work with the check_event gui > interface, but the necessary change in the interface should be minimal. Can this indeed be done? Max told me that somethings are also disallowed during the painting phase in Qt. Can we process events during drawing, or should we first return to the main loop? Long live old-fashioned GUI API's... --Joris _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Bugzilla from josef.weidendorfer@gmx.de
::
Rate this Message:
On Wednesday 14 October 2009, Alex D wrote:
> If I understand correctly, the -graphicssystem raster switch tells the Qt > library to use a different graphics backend that performs rendering and text > rasterization in software (on the client) instead of relying on the server > (X11). AFAIK correct, yes. > I heard that these performance issues were due to performance regressions > recently introduced into the Intel graphics drivers. However, the upcoming > version of Ubuntu, Karmic Koala, introduces newer drivers which are supposed > to fix all these issues. I'll do some testing when it comes out later this > month. > > Setting the switch is the only way to force graphicssystem raster for a > particular application short of recompiling the libraries. This can be done > with a wrapper script. No, you can change the render backend also from your Qt application, via Application::setGraphicsSystem("raster"); (Qt version >= 4.5). But... > > Could it be set permanently? ... please do not do this. Depending on the system, it also can have huge negative effects, e.g. with slow CPU but graphics HW acceleration (without bugs in the driver). Also, if X does not run on the same system (ie. remote), it will result in huge pixmap data to be copied on every update, similar to VNC. Josef _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Norbert Nemec
::
Rate this Message:
Joris van der Hoeven wrote:
> On Wed, Oct 14, 2009 at 05:27:03PM +0100, Norbert Nemec wrote: > >> >> Indeed. I guess a proper approach on Qt would be to use processEvents >> frequently during drawing. This does not work with the check_event gui >> interface, but the necessary change in the interface should be minimal. >> > > Can this indeed be done? Max told me that somethings are also disallowed > during the painting phase in Qt. Can we process events during drawing, > or should we first return to the main loop? Long live old-fashioned GUI API's... > http://lists.trolltech.com/qt-interest/1997-08/thread00023-0.htm This seems to suggest that it is not impossible in principle, just a bit tricky. Another source on the web warns in principle: http://www.kdab.net/~dfaure/conf/Malaga_AsyncProgramming/html/slide_5.html but this might simply refer to issues like the one discussed in the thread before. As far as I see it, the main danger is that inside the TeXmacs code, one must be aware that paintEvent might still be on the stack. The whole thing certainly is tricky but I think it should be possible. Greetings, Norbert _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Joris van der Hoeven
::
Rate this Message:
On Thu, Oct 15, 2009 at 06:11:52PM +0100, Norbert Nemec wrote:
> Joris van der Hoeven wrote: > >On Wed, Oct 14, 2009 at 05:27:03PM +0100, Norbert Nemec wrote: > > > >> > >>Indeed. I guess a proper approach on Qt would be to use processEvents > >>frequently during drawing. This does not work with the check_event gui > >>interface, but the necessary change in the interface should be minimal. > >> > > > >Can this indeed be done? Max told me that somethings are also disallowed > >during the painting phase in Qt. Can we process events during drawing, > >or should we first return to the main loop? Long live old-fashioned GUI > >API's... > > > I just found an ancient thread about calling processEvents from paintEvent > http://lists.trolltech.com/qt-interest/1997-08/thread00023-0.htm > > This seems to suggest that it is not impossible in principle, just a bit > tricky. > > Another source on the web warns in principle: > > http://www.kdab.net/~dfaure/conf/Malaga_AsyncProgramming/html/slide_5.html > > but this might simply refer to issues like the one discussed in the > thread before. As far as I see it, the main danger is that inside the > TeXmacs code, one must be aware that paintEvent might still be on the > stack. The whole thing certainly is tricky but I think it should be > possible. Max: how feasable is the following strategy: check_event calls processEvents after setting a global variable that we are repainting something. In each of the event handlers, if this global variable is set, then either process the event if it is an independent non-blocking event, and transform the event in a delayed command if not, return to the repainting code and set the tell repainting to interrupt. Best wishes, --Joris _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Massimiliano Gubinelli
::
Rate this Message:
Hi all,
On 15 oct. 09, at 22:02, Joris van der Hoeven wrote: > On Thu, Oct 15, 2009 at 06:11:52PM +0100, Norbert Nemec wrote: >> Joris van der Hoeven wrote: >>> On Wed, Oct 14, 2009 at 05:27:03PM +0100, Norbert Nemec wrote: >>> >>>> >>>> Indeed. I guess a proper approach on Qt would be to use >>>> processEvents >>>> frequently during drawing. This does not work with the >>>> check_event gui >>>> interface, but the necessary change in the interface should be >>>> minimal. >>>> >>> >>> Can this indeed be done? Max told me that somethings are also >>> disallowed >>> during the painting phase in Qt. Can we process events during >>> drawing, >>> or should we first return to the main loop? Long live old- >>> fashioned GUI >>> API's... >>> >> I just found an ancient thread about calling processEvents from >> paintEvent >> http://lists.trolltech.com/qt-interest/1997-08/thread00023-0.htm >> >> This seems to suggest that it is not impossible in principle, just >> a bit >> tricky. >> >> Another source on the web warns in principle: >> >> http://www.kdab.net/~dfaure/conf/Malaga_AsyncProgramming/html/slide_5.html >> >> but this might simply refer to issues like the one discussed in the >> thread before. As far as I see it, the main danger is that inside the >> TeXmacs code, one must be aware that paintEvent might still be on the >> stack. The whole thing certainly is tricky but I think it should be >> possible. > > Max: how feasable is the following strategy: check_event calls > processEvents after setting a global variable that we are repainting > something. > In each of the event handlers, if this global variable is set, > then either process the event if it is an independent non-blocking > event, > and transform the event in a delayed command if not, > return to the repainting code and set the tell repainting to > interrupt. I agree that something like this should work. What about the following more uniform scheme: each Qt event handler performs some basic computations (which do not require involvement of TeXmacs objects) enough to determine an appopriate function call into TeXmacs which is then boxed as abstract command and inserted in the delayed messages queue. This would allow to return as fast as possible to the event loop. Inside check_events should then be safe to call processEvents which could result in filling up the delayed- messages queue by some input commands (keypresses or mouse movements). If this is the case we can set some flags so that check_events can interrupt the drawing process and return to the main event loop. At this point the delayed messages can be processed. This would have the added bonus of giving us the control of the events already preprocessed so that, for example, we can skip some mouse move events if they are too many, or process all the key events, etc... I still have some doubts about the handling of socket events. Max _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
Re: Two fixes for delayed execution
by Joris van der Hoeven
::
Rate this Message:
On Sat, Oct 17, 2009 at 12:15:08AM +0200, Gubinelli Massimiliano wrote:
> I agree that something like this should work. What about the following > more uniform scheme: > each Qt event handler performs some basic computations (which do not > require involvement of TeXmacs objects) > enough to determine an appopriate function call into TeXmacs which is > then boxed as abstract command and inserted in the > delayed messages queue. This would allow to return as fast as > possible to the event loop. Inside check_events should then be safe to > call processEvents which could result in filling up the delayed- > messages queue by some input commands (keypresses or mouse movements). > If this is the case we can set some flags so that check_events can > interrupt the drawing process and return to the main event loop. At > this point the delayed messages can be processed. This would have the > added bonus of giving us the control of the events already > preprocessed so that, for example, we can skip some mouse move events > if they are too many, or process all the key events, etc... > I still have some doubts about the handling of socket events. If this would not be t much a hassle for you to implement, then this seems like an excellent idea. Indeed, at certain times it can be interesting to preprocess the input events. Best wishes, --Joris _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
|
|
TeXmacs/Qt on intel graphics (Re: Two fixes for delayed execution)
by Norbert Nemec
::
Rate this Message:
Alex D wrote:
> If I understand correctly, the -graphicssystem raster switch tells the > Qt library to use a different graphics backend that performs rendering > and text rasterization in software (on the client) instead of relying > on the server (X11). > > I heard that these performance issues were due to performance > regressions recently introduced into the Intel graphics drivers. > However, the upcoming version of Ubuntu, Karmic Koala, introduces > newer drivers which are supposed to fix all these issues. I'll do some > testing when it comes out later this month. I just checked: my system is already running with the new UXA setting. It does not solve the problem. Running TeXmacs/Qt without switches, even simple cursor movements through a plain text bring the CPU load of the X server up to 98% and TeXmacs becomes painfully sluggish. Setting the "-graphicssystem raster" command line option fixes the problem. Greetings, Norbert > > Setting the switch is the only way to force graphicssystem raster for > a particular application short of recompiling the libraries. This can > be done with a wrapper script. > > --Alex Dobkin > > On Wed, Oct 14, 2009 at 11:19 AM, Norbert Nemec > <Norbert.Nemec.list@... <mailto:Norbert.Nemec.list@...>> wrote: > > Wow, indeed! X server load goes down to 30% when I move through a > long text. Sluggishness is completely gone... > > What does that switch do? Could it be set permanently? Does it > affect only Intel graphics hardware? > > Greetings, > Norbert > > > > Alex D wrote: > > Hi, > > In case anyone is runing the Qt port on Intel graphics > hardware on Ubuntu or similar systems and experiencing > sluggish performance, a suggestion is to run the application > with the '-graphicssystem raster' switch enabled. This yields > greatly improved performance in my case. > > --Alex Dobkin > > On Wed, Oct 14, 2009 at 5:04 AM, Gubinelli Massimiliano > <m.gubinelli@... <mailto:m.gubinelli@...> > <mailto:m.gubinelli@... <mailto:m.gubinelli@...>>> > wrote: > > Hi, > > > On 13 oct. 09, at 22:32, Norbert Nemec wrote: > > In fact, I found a clear measurement that indicates a > problem: > > Running TeXmacs/Qt on my fairly modern notebook (fully > optimized compile). > > I fill one page with plain text. Now simply moving > through the > text with the right arrow (no editing!) brings up the > CPU load > to 100%. Of this, 95% are spent in the X server. TeXmacs > itself only takes 5% of the CPU power. > > > I can confirm this observation. In my ubuntu virtual machine > (VirtualBox/MacOSX) the above protocol gives \sim 75% CPU > load to > Xorg and \sim 23% to texmacs. You should check that you do > not use > cairo since at the moment the cairo rendering is slightly > unoptimal in QT (explicit and naive double-buffer). > On my mac the load remains reasonable (30% which should include > the GUI load also since the total CPU load is not much higher). > > Proprer implementation of check_event require knowing if > there are > pending key events in the queue and this is not possible in > Qt (or > even in Cocoa). Moderns GUI API explicitly discurage looking at > the event queue so we should design a different mechanism to > reimplement what it is currently done in the X11 port. > > > best > max > > > > I tried activating the code in check_event. The display is > incomplete now, but the CPU load is down to 30% and TeXmacs > feels fully reactive. > > > Seems like this optimization is crucial not only for slow > machines after all... > > > > > > Greetings, > Norbert > > > > > Joris van der Hoeven wrote: > > On Tue, Oct 13, 2009 at 05:14:02PM +0200, Álvaro Tejero > Cantero wrote: > > I didn't notice any problems, but TeXmacs-QT feels > slower already when > typing at the end of 3-line paragraphs. > > > That is shortcoming of the current Qt version: > interrupts during the rendering phase have not yet been > implemented. > Now that delayed_event has become cleaner, maybe > Max can > fix that one too. > > > Is there any more quantitative way to test > performance? > > > This is rather a matter of reactivity. Hard to measure. > > Best wishes, --Joris > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > <mailto:Texmacs-dev@... <mailto:Texmacs-dev@...>> > > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > <mailto:Texmacs-dev@... <mailto:Texmacs-dev@...>> > > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > <mailto:Texmacs-dev@... <mailto:Texmacs-dev@...>> > > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > > > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... <mailto:Texmacs-dev@...> > http://lists.gnu.org/mailman/listinfo/texmacs-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Texmacs-dev mailing list > Texmacs-dev@... > http://lists.gnu.org/mailman/listinfo/texmacs-dev > _______________________________________________ Texmacs-dev mailing list Texmacs-dev@... http://lists.gnu.org/mailman/listinfo/texmacs-dev |
| Free embeddable forum powered by Nabble | Forum Help |
