Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: I've applied attached patch which only eats page up/down keys on x11 and fixes the scrollbar scrolling bug. This is a conservative approach. And because we really need more testing until the release it is now in svn (I know, I know, I know,... but somehow this thread must find an end, and we could still revert). Here the bugzilla entries: http://bugzilla.lyx.org/show_bug.cgi?id=3652 Don't know about this one, I don't have the equipment. http://bugzilla.lyx.org/show_bug.cgi?id=3320 Problem solved, I recommended to close the bugzilla entry. The unpatched LyX revision 18646 works great for me! Thanks for all the work on fixing this problem! Helge Hafting
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: I've applied attached patch which only eats page up/down keys on x11 and fixes the scrollbar scrolling bug. This is a conservative approach. And because we really need more testing until the release it is now in svn (I know, I know, I know,... but somehow this thread must find an end, and we could still revert). Here the bugzilla entries: http://bugzilla.lyx.org/show_bug.cgi?id=3652 Don't know about this one, I don't have the equipment. http://bugzilla.lyx.org/show_bug.cgi?id=3320 Problem solved, I recommended to close the bugzilla entry. The unpatched LyX revision 18646 works great for me! Thanks for all the work on fixing this problem! Helge Hafting
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: Peter Kümmel wrote: I've applied attached patch which only eats page up/down keys on x11 and fixes the scrollbar scrolling bug. This is a conservative approach. And because we really need more testing until the release it is now in svn (I know, I know, I know,... but somehow this thread must find an end, and we could still revert). Here the bugzilla entries: http://bugzilla.lyx.org/show_bug.cgi?id=3652 http://bugzilla.lyx.org/show_bug.cgi?id=3320 Peter Peter, I like this behavior better than the previous situation... :) Thanks for testing Dov, I'm glad to hear you've not found a new bug ;) Peter
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: > Peter Kümmel wrote: >> I've applied attached patch which only eats page up/down keys on x11 >> and fixes the scrollbar scrolling bug. This is a conservative approach. >> >> And because we really need more testing until the release it >> is now in svn (I know, I know, I know,... but somehow this >> thread must find an end, and we could still revert). >> >> Here the bugzilla entries: >> http://bugzilla.lyx.org/show_bug.cgi?id=3652 >> http://bugzilla.lyx.org/show_bug.cgi?id=3320 >> >> Peter >> > > Peter, I like this behavior better than the previous situation... :) > Thanks for testing Dov, I'm glad to hear you've not found a new bug ;) Peter
Re: Scrolling lag in 1.5svn again, more details.
I've applied attached patch which only eats page up/down keys on x11
and fixes the scrollbar scrolling bug. This is a conservative approach.
And because we really need more testing until the release it
is now in svn (I know, I know, I know,... but somehow this
thread must find an end, and we could still revert).
Here the bugzilla entries:
http://bugzilla.lyx.org/show_bug.cgi?id=3652
http://bugzilla.lyx.org/show_bug.cgi?id=3320
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18628)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -48,6 +48,11 @@
#include boost/bind.hpp
#include boost/current_function.hpp
+#ifdef Q_WS_X11
+#include QX11Info
+extern C int XEventsQueued(Display *display, int mode);
+#endif
+
#ifdef Q_WS_WIN
int const CursorWidth = 2;
#else
@@ -234,6 +239,7 @@
void GuiWorkArea::adjustViewWithScrollBar(int)
{
scrollBufferView(verticalScrollBar()-sliderPosition());
+ QApplication::syncX();
}
@@ -414,6 +420,19 @@
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
+ // do nothing if there are other events
+ // (the auto repeated events come too fast)
+ // \todo FIXME: remove hard coded Qt keysprocess the key binding
+#ifdef Q_WS_X11
+ if (XEventsQueued(QX11Info::display(), 0) 1e-isAutoRepeat()
+(Qt::Key_PageDown || Qt::Key_PageUp)) {
+ LYXERR(Debug::KEY)
+BOOST_CURRENT_FUNCTION endl
+sysstem is busy: scroll key event ignored endl;
+ e-ignore();
+ return;
+ }
+#endif
LYXERR(Debug::KEY) BOOST_CURRENT_FUNCTION
count= e-count()
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: I've applied attached patch which only eats page up/down keys on x11 and fixes the scrollbar scrolling bug. This is a conservative approach. And because we really need more testing until the release it is now in svn (I know, I know, I know,... but somehow this thread must find an end, and we could still revert). Here the bugzilla entries: http://bugzilla.lyx.org/show_bug.cgi?id=3652 http://bugzilla.lyx.org/show_bug.cgi?id=3320 Peter Peter, I like this behavior better than the previous situation... :)
Re: Scrolling lag in 1.5svn again, more details.
I've applied attached patch which only eats page up/down keys on x11
and fixes the scrollbar scrolling bug. This is a conservative approach.
And because we really need more testing until the release it
is now in svn (I know, I know, I know,... but somehow this
thread must find an end, and we could still revert).
Here the bugzilla entries:
http://bugzilla.lyx.org/show_bug.cgi?id=3652
http://bugzilla.lyx.org/show_bug.cgi?id=3320
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18628)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -48,6 +48,11 @@
#include
#include
+#ifdef Q_WS_X11
+#include
+extern "C" int XEventsQueued(Display *display, int mode);
+#endif
+
#ifdef Q_WS_WIN
int const CursorWidth = 2;
#else
@@ -234,6 +239,7 @@
void GuiWorkArea::adjustViewWithScrollBar(int)
{
scrollBufferView(verticalScrollBar()->sliderPosition());
+ QApplication::syncX();
}
@@ -414,6 +420,19 @@
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
+ // do nothing if there are other events
+ // (the auto repeated events come too fast)
+ // \todo FIXME: remove hard coded Qt keysprocess the key binding
+#ifdef Q_WS_X11
+ if (XEventsQueued(QX11Info::display(), 0) > 1 && e->isAutoRepeat()
+ && (Qt::Key_PageDown || Qt::Key_PageUp)) {
+ LYXERR(Debug::KEY)
+ << BOOST_CURRENT_FUNCTION << endl
+ << "sysstem is busy: scroll key event ignored" << endl;
+ e->ignore();
+ return;
+ }
+#endif
LYXERR(Debug::KEY) << BOOST_CURRENT_FUNCTION
<< " count=" << e->count()
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: I've applied attached patch which only eats page up/down keys on x11 and fixes the scrollbar scrolling bug. This is a conservative approach. And because we really need more testing until the release it is now in svn (I know, I know, I know,... but somehow this thread must find an end, and we could still revert). Here the bugzilla entries: http://bugzilla.lyx.org/show_bug.cgi?id=3652 http://bugzilla.lyx.org/show_bug.cgi?id=3320 Peter Peter, I like this behavior better than the previous situation... :)
Re: Scrolling lag in 1.5svn again, more details.
On Thu, May 31, 2007 at 11:22:56PM +0200, Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | | Or happens the dropping only to auto repeated keys? | | Only auto-repeated keys. | | OK, if you are really sure only auto-repeated keys will be dropped, | I think your patch should go into RC1. | | BUT, I also had a Qt based patch which only discards auto repeated | keys, and Martin had a counter-argument, 'word completion': then put my queue of events back in and we can controll the events ourselves. qt does not give us acess to its event queue. btw. I think this nokia thingie is doing something dubious. And I am not sure we should care (much). I might agree on the second count. But I'm not sure about the first: the nokia thingie is working just fine with vim, gedit, browser textboxes etc. Only LyX misbehaves. Anyway it's not a big enough problem to care about in and of itself -- too special. And I can not use word completion anyway. - Martin
Re: Scrolling lag in 1.5svn again, more details.
On Fri, Jun 01, 2007 at 01:44:32PM +0300, Martin Vermeer wrote: On Thu, May 31, 2007 at 11:22:56PM +0200, Lars Gullik Bjønnes wrote: ... | keys, and Martin had a counter-argument, 'word completion': then put my queue of events back in and we can controll the events ourselves. qt does not give us acess to its event queue. btw. I think this nokia thingie is doing something dubious. And I am not sure we should care (much). I might agree on the second count. But I'm not sure about the first: the nokia thingie is working just fine with vim, gedit, browser textboxes etc. Only LyX misbehaves. Anyway it's not a big enough problem to care about in and of itself -- too special. And I can not use word completion anyway. What I meant: I can _choose to_ not use... - Martin
Re: Scrolling lag in 1.5svn again, more details.
On Thu, May 31, 2007 at 11:22:56PM +0200, Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | Peter Kümmel wrote: > | >> | Or happens the dropping only to auto repeated keys? > | >> > | >> Only auto-repeated keys. > | > > | > OK, if you are really sure only auto-repeated keys will be dropped, > | > I think your patch should go into RC1. > | > | BUT, I also had a Qt based patch which only discards auto repeated > | keys, and Martin had a counter-argument, 'word completion': > > then put my queue of events back in and we can controll the events > ourselves. qt does not give us acess to its event queue. > > btw. I think this nokia thingie is doing something dubious. And I am > not sure we should care (much). I might agree on the second count. But I'm not sure about the first: the nokia thingie is working just fine with vim, gedit, browser textboxes etc. Only LyX misbehaves. Anyway it's not a big enough problem to care about in and of itself -- too special. And I can not use word completion anyway. - Martin
Re: Scrolling lag in 1.5svn again, more details.
On Fri, Jun 01, 2007 at 01:44:32PM +0300, Martin Vermeer wrote: > On Thu, May 31, 2007 at 11:22:56PM +0200, Lars Gullik Bjønnes wrote: ... > > | keys, and Martin had a counter-argument, 'word completion': > > > > then put my queue of events back in and we can controll the events > > ourselves. qt does not give us acess to its event queue. > > > > btw. I think this nokia thingie is doing something dubious. And I am > > not sure we should care (much). > > I might agree on the second count. But I'm not sure about the first: > the nokia thingie is working just fine with vim, gedit, browser textboxes > etc. Only LyX misbehaves. > > Anyway it's not a big enough problem to care about in and of itself -- too > special. And I can not use word completion anyway. What I meant: I can _choose to_ not use... - Martin
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: The event_1 patch gives better results on systems with a fast enough graphic card(?) but does not work an older systems. Jose feel free to do what you want. What is the outcome of your email exchange with Helge and Lars on this subject? This is an area where that looks like a landmine area, you step in the wrong place and ... Peter -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
José Matos wrote: On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: The event_1 patch gives better results on systems with a fast enough graphic card(?) but does not work an older systems. Jose feel free to do what you want. What is the outcome of your email exchange with Helge and Lars on this subject? This is an area where that looks like a landmine area, you step in the wrong place and ... Peter I'm pretty sure what's going on when my patch eats key events. Currently only pageup/pagedown key events are dropped. But JMark wants a more general approach so that also key gets dropped which are mapped by a binding to the scrolling keys. I don't know if Lars' patch is better. For the scrollbar scrolling no patch exists. So any of my patch posted to the list should not go in. But one patch which at least fixes the pageup/down-key scrolling should go in before RC1. Peter
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 31 May 2007 20:35:06 Peter Kümmel wrote: But one patch which at least fixes the pageup/down-key scrolling should go in before RC1. I intend to release RC1 really soon now, so this patch must wait for RC2. Peter -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel [EMAIL PROTECTED] writes: | José Matos wrote: | On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: | The event_1 patch gives better results on systems | with a fast enough graphic card(?) but does not work | an older systems. | | Jose feel free to do what you want. | |What is the outcome of your email exchange with Helge and Lars on this | subject? | |This is an area where that looks like a landmine area, you step in the wrong | place and ... | | Peter | | | | I'm pretty sure what's going on when my patch eats key events. | Currently only pageup/pagedown key events are dropped. | But JMark wants a more general approach so that also key gets | dropped which are mapped by a binding to the scrolling keys. | I don't know if Lars' patch is better. My patch works for all key variants. that is entered through auto-keying. Basically all key events that we failt to handle because auto-repeat is too fast are dropped. -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 31 May 2007 20:50:54 Lars Gullik Bjønnes wrote: My patch works for all key variants. that is entered through auto-keying. Basically all key events that we failt to handle because auto-repeat is too fast are dropped. What is the drawback then? -- Lgb -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | José Matos wrote: | On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: | The event_1 patch gives better results on systems | with a fast enough graphic card(?) but does not work | an older systems. | | Jose feel free to do what you want. | |What is the outcome of your email exchange with Helge and Lars on this | subject? | |This is an area where that looks like a landmine area, you step in the wrong | place and ... | | Peter | | | | I'm pretty sure what's going on when my patch eats key events. | Currently only pageup/pagedown key events are dropped. | But JMark wants a more general approach so that also key gets | dropped which are mapped by a binding to the scrolling keys. | I don't know if Lars' patch is better. My patch works for all key variants. that is entered through auto-keying. Basically all key events that we failt to handle because auto-repeat is too fast are dropped. And no keys will be dropped? We could also put in your patch, as it is only a problem on Linux. Do you think we could use QApplication::synxX() instead of the X11 call? -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
José Matos [EMAIL PROTECTED] writes: | On Thursday 31 May 2007 20:50:54 Lars Gullik Bjønnes wrote: | My patch works for all key variants. that is entered through | auto-keying. Basically all key events that we failt to handle because | auto-repeat is too fast are dropped. | | What is the drawback then? Nothing? That is only handles key-events and not mouse-events? Direct calls to X-lib functions? -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote:
And no keys will be dropped?
We could also put in your patch, as it is only a problem on Linux.
Do you think we could use QApplication::synxX() instead of the X11
call?
The Qt code:
http://websvn.kde.org/*checkout*/trunk/qt-copy/src/gui/kernel/qapplication_x11.cpp?content-type=text%2Fplain
void QApplication::syncX()
{
if (X11-display)
XSync(X11-display, False);// don't discard
events
}
Seems we could use this function instead.
Peter
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Peter Kümmel [EMAIL PROTECTED] writes: | | | José Matos wrote: | | On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: | | The event_1 patch gives better results on systems | | with a fast enough graphic card(?) but does not work | | an older systems. | | | | Jose feel free to do what you want. | | | |What is the outcome of your email exchange with Helge and Lars on this | | subject? | | | |This is an area where that looks like a landmine area, you step in the wrong | | place and ... | | | | Peter | | | | | | | | I'm pretty sure what's going on when my patch eats key events. | | Currently only pageup/pagedown key events are dropped. | | But JMark wants a more general approach so that also key gets | | dropped which are mapped by a binding to the scrolling keys. | | I don't know if Lars' patch is better. | | My patch works for all key variants. that is entered through | auto-keying. Basically all key events that we failt to handle because | auto-repeat is too fast are dropped. | | | And no keys will be dropped? If you go aab then the b, might be dropped. I have not tested. But sure, quite a few will be dropped. (which is just what we want if we are too slow to get them in.) | We could also put in your patch, as it is only a problem on Linux. | Do you think we could use QApplication::synxX() instead of the X11 | call? If I remember correctly, that call did the wrong thing. -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel [EMAIL PROTECTED] writes:
| Peter Kümmel wrote:
|
| And no keys will be dropped?
|
| We could also put in your patch, as it is only a problem on Linux.
| Do you think we could use QApplication::synxX() instead of the X11
| call?
|
| The Qt code:
|
http://websvn.kde.org/*checkout*/trunk/qt-copy/src/gui/kernel/qapplication_x11.cpp?content-type=text%2Fplain
|
| void QApplication::syncX()
| {
| if (X11-display)
| XSync(X11-display, False);// don't discard
events
| }
|
|
| Seems we could use this function instead.
Did you test? It is not equal to the XSync I use.
False - True
I am quite certain the True is required.
And we still need the XEventsQueued.
--
Lgb
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Peter Kümmel [EMAIL PROTECTED] writes: | | | José Matos wrote: | | On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: | | The event_1 patch gives better results on systems | | with a fast enough graphic card(?) but does not work | | an older systems. | | | | Jose feel free to do what you want. | | | |What is the outcome of your email exchange with Helge and Lars on this | | subject? | | | |This is an area where that looks like a landmine area, you step in the wrong | | place and ... | | | | Peter | | | | | | | | I'm pretty sure what's going on when my patch eats key events. | | Currently only pageup/pagedown key events are dropped. | | But JMark wants a more general approach so that also key gets | | dropped which are mapped by a binding to the scrolling keys. | | I don't know if Lars' patch is better. | | My patch works for all key variants. that is entered through | auto-keying. Basically all key events that we failt to handle because | auto-repeat is too fast are dropped. | | | And no keys will be dropped? If you go aab then the b, might be dropped. I have not tested. But sure, quite a few will be dropped. (which is just what we want if we are too slow to get them in.) What if you have a slow system but you type with your 12 ;) fingers at a rate of 20 types per second. Then it is not a problem to type as sentence and then to wait a bit until all gets in. Or happens the dropping only to auto repeated keys? | We could also put in your patch, as it is only a problem on Linux. | Do you think we could use QApplication::synxX() instead of the X11 | call? If I remember correctly, that call did the wrong thing. -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote:
Peter Kümmel [EMAIL PROTECTED] writes:
| Peter Kümmel wrote:
|
| And no keys will be dropped?
|
| We could also put in your patch, as it is only a problem on Linux.
| Do you think we could use QApplication::synxX() instead of the X11
| call?
|
| The Qt code:
|
http://websvn.kde.org/*checkout*/trunk/qt-copy/src/gui/kernel/qapplication_x11.cpp?content-type=text%2Fplain
|
| void QApplication::syncX()
| {
| if (X11-display)
| XSync(X11-display, False);// don't discard
events
| }
|
|
| Seems we could use this function instead.
Did you test? It is not equal to the XSync I use.
No, I didn't.
False - True
OK, I thought it was also False in your patch.
I am quite certain the True is required.
http://tronche.com/gui/x/xlib/event-handling/XSync.html
yes, true enables discarding.
And we still need the XEventsQueued.
--
Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel [EMAIL PROTECTED] writes: | If you go aab | then the b, might be dropped. I have not tested. | | But sure, quite a few will be dropped. (which is just what we | want if we are too slow to get them in.) | | | What if you have a slow system but you type with your 12 ;) | fingers at a rate of 20 types per second. Then it is not a problem | to type as sentence and then to wait a bit until all gets in. | | Or happens the dropping only to auto repeated keys? Only auto-repeated keys. -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | If you go aab | then the b, might be dropped. I have not tested. | | But sure, quite a few will be dropped. (which is just what we | want if we are too slow to get them in.) | | | What if you have a slow system but you type with your 12 ;) | fingers at a rate of 20 types per second. Then it is not a problem | to type as sentence and then to wait a bit until all gets in. | | Or happens the dropping only to auto repeated keys? Only auto-repeated keys. OK, if you are really sure only auto-repeated keys will be dropped, I think your patch should go into RC1. -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Peter Kümmel [EMAIL PROTECTED] writes:
|
| | If you go aab
| | then the b, might be dropped. I have not tested.
| |
| | But sure, quite a few will be dropped. (which is just what we
| | want if we are too slow to get them in.)
| |
| |
| | What if you have a slow system but you type with your 12 ;)
| | fingers at a rate of 20 types per second. Then it is not a problem
| | to type as sentence and then to wait a bit until all gets in.
| |
| | Or happens the dropping only to auto repeated keys?
|
| Only auto-repeated keys.
|
| OK, if you are really sure only auto-repeated keys will be dropped,
| I think your patch should go into RC1.
Yes, quite sure
+ if (e-isAutoRepeat()) {
+ ...
+ }
--
Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | | Or happens the dropping only to auto repeated keys? | | Only auto-repeated keys. | | OK, if you are really sure only auto-repeated keys will be dropped, | I think your patch should go into RC1. | | BUT, I also had a Qt based patch which only discards auto repeated | keys, and Martin had a counter-argument, 'word completion': then put my queue of events back in and we can controll the events ourselves. qt does not give us acess to its event queue. btw. I think this nokia thingie is doing something dubious. And I am not sure we should care (much). -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: | Or happens the dropping only to auto repeated keys? Only auto-repeated keys. OK, if you are really sure only auto-repeated keys will be dropped, I think your patch should go into RC1. BUT, I also had a Qt based patch which only discards auto repeated keys, and Martin had a counter-argument, 'word completion': http://marc.info/?l=lyx-develm=117947257615003w=2 http://marc.info/?l=lyx-develm=117948429913972w=2
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote:
Peter Kümmel [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Peter Kümmel [EMAIL PROTECTED] writes:
|
| | If you go aab
| | then the b, might be dropped. I have not tested.
| |
| | But sure, quite a few will be dropped. (which is just what we
| | want if we are too slow to get them in.)
| |
| |
| | What if you have a slow system but you type with your 12 ;)
| | fingers at a rate of 20 types per second. Then it is not a problem
| | to type as sentence and then to wait a bit until all gets in.
| |
| | Or happens the dropping only to auto repeated keys?
|
| Only auto-repeated keys.
|
| OK, if you are really sure only auto-repeated keys will be dropped,
| I think your patch should go into RC1.
Yes, quite sure
+ if (e-isAutoRepeat()) {
+ ...
+ }
Here I've also used isAutoRepeat()
http://marc.info/?l=lyx-develm=117938755501254w=2
but we couldn't use it, maybe a Qt bug?
http://marc.info/?l=lyx-develm=117951666017572w=2
So I should have a look again at this mail from Richard
http://marc.info/?l=lyx-develm=117952595711747w=2
--
Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 31 May 2007 22:05:31 Lars Gullik Bjønnes wrote:
Yes, quite sure
+ if (e-isAutoRepeat()) {
+ ...
+ }
Could you shove it in, please?
--
Lgb
--
José Abílio
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | | Or happens the dropping only to auto repeated keys? | | Only auto-repeated keys. | | OK, if you are really sure only auto-repeated keys will be dropped, | I think your patch should go into RC1. | | BUT, I also had a Qt based patch which only discards auto repeated | keys, and Martin had a counter-argument, 'word completion': then put my queue of events back in and we can controll the events ourselves. qt does not give us acess to its event queue. What is your queue of events ? btw. I think this nokia thingie is doing something dubious. And I am not sure we should care (much). Yes, it's a little bit exotic. -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: > The event_1 patch gives better results on systems > with a fast enough graphic card(?) but does not work > an older systems. > > Jose feel free to do what you want. What is the outcome of your email exchange with Helge and Lars on this subject? This is an area where that looks like a landmine area, you step in the wrong place and ... > Peter -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
José Matos wrote: > On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: >> The event_1 patch gives better results on systems >> with a fast enough graphic card(?) but does not work >> an older systems. >> >> Jose feel free to do what you want. > > What is the outcome of your email exchange with Helge and Lars on this > subject? > > This is an area where that looks like a landmine area, you step in the > wrong > place and ... > >> Peter > I'm pretty sure what's going on when my patch "eats" key events. Currently only pageup/pagedown key events are dropped. But JMark wants a more general approach so that also key gets dropped which are mapped by a binding to the scrolling keys. I don't know if Lars' patch is better. For the scrollbar scrolling no patch exists. So any of my patch posted to the list should not go in. But one patch which at least fixes the pageup/down-key scrolling should go in before RC1. Peter
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 31 May 2007 20:35:06 Peter Kümmel wrote: > But one patch which at least fixes the pageup/down-key scrolling > should go in before RC1. I intend to release RC1 really soon now, so this patch must wait for RC2. > Peter -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel <[EMAIL PROTECTED]> writes: | José Matos wrote: | > On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: | >> The event_1 patch gives better results on systems | >> with a fast enough graphic card(?) but does not work | >> an older systems. | >> | >> Jose feel free to do what you want. | > | > What is the outcome of your email exchange with Helge and Lars on this | > subject? | > | > This is an area where that looks like a landmine area, you step in the wrong | > place and ... | > | >> Peter | > | | | I'm pretty sure what's going on when my patch "eats" key events. | Currently only pageup/pagedown key events are dropped. | But JMark wants a more general approach so that also key gets | dropped which are mapped by a binding to the scrolling keys. | I don't know if Lars' patch is better. My patch works for all "key" variants. that is entered through auto-keying. Basically all key events that we failt to handle because auto-repeat is too fast are dropped. -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 31 May 2007 20:50:54 Lars Gullik Bjønnes wrote: > My patch works for all "key" variants. that is entered through > auto-keying. Basically all key events that we failt to handle because > auto-repeat is too fast are dropped. What is the drawback then? > -- > Lgb -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | José Matos wrote: > | > On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: > | >> The event_1 patch gives better results on systems > | >> with a fast enough graphic card(?) but does not work > | >> an older systems. > | >> > | >> Jose feel free to do what you want. > | > > | > What is the outcome of your email exchange with Helge and Lars on this > | > subject? > | > > | > This is an area where that looks like a landmine area, you step in the > wrong > | > place and ... > | > > | >> Peter > | > > | > | > | I'm pretty sure what's going on when my patch "eats" key events. > | Currently only pageup/pagedown key events are dropped. > | But JMark wants a more general approach so that also key gets > | dropped which are mapped by a binding to the scrolling keys. > | I don't know if Lars' patch is better. > > My patch works for all "key" variants. that is entered through > auto-keying. Basically all key events that we failt to handle because > auto-repeat is too fast are dropped. > And no keys will be dropped? We could also put in your patch, as it is only a problem on Linux. Do you think we could use QApplication::synxX() instead of the X11 call? -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
José Matos <[EMAIL PROTECTED]> writes: | On Thursday 31 May 2007 20:50:54 Lars Gullik Bjønnes wrote: | > My patch works for all "key" variants. that is entered through | > auto-keying. Basically all key events that we failt to handle because | > auto-repeat is too fast are dropped. | | What is the drawback then? Nothing? That is only handles key-events and not mouse-events? Direct calls to X-lib functions? -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote:
>
> And no keys will be dropped?
>
> We could also put in your patch, as it is only a problem on Linux.
> Do you think we could use QApplication::synxX() instead of the X11
> call?
The Qt code:
http://websvn.kde.org/*checkout*/trunk/qt-copy/src/gui/kernel/qapplication_x11.cpp?content-type=text%2Fplain
void QApplication::syncX()
{
if (X11->display)
XSync(X11->display, False);// don't discard
events
}
Seems we could use this function instead.
Peter
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > Peter Kümmel <[EMAIL PROTECTED]> writes: | > | > | José Matos wrote: | > | > On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: | > | >> The event_1 patch gives better results on systems | > | >> with a fast enough graphic card(?) but does not work | > | >> an older systems. | > | >> | > | >> Jose feel free to do what you want. | > | > | > | > What is the outcome of your email exchange with Helge and Lars on this | > | > subject? | > | > | > | > This is an area where that looks like a landmine area, you step in the wrong | > | > place and ... | > | > | > | >> Peter | > | > | > | | > | | > | I'm pretty sure what's going on when my patch "eats" key events. | > | Currently only pageup/pagedown key events are dropped. | > | But JMark wants a more general approach so that also key gets | > | dropped which are mapped by a binding to the scrolling keys. | > | I don't know if Lars' patch is better. | > | > My patch works for all "key" variants. that is entered through | > auto-keying. Basically all key events that we failt to handle because | > auto-repeat is too fast are dropped. | > | | And no keys will be dropped? If you go aab then the b, might be dropped. I have not tested. But sure, quite a few will be dropped. (which is just what we want if we are too slow to get them in.) | We could also put in your patch, as it is only a problem on Linux. | Do you think we could use QApplication::synxX() instead of the X11 | call? If I remember correctly, that call did the wrong thing. -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Peter Kümmel wrote:
| >
| > And no keys will be dropped?
| >
| > We could also put in your patch, as it is only a problem on Linux.
| > Do you think we could use QApplication::synxX() instead of the X11
| > call?
|
| The Qt code:
|
http://websvn.kde.org/*checkout*/trunk/qt-copy/src/gui/kernel/qapplication_x11.cpp?content-type=text%2Fplain
|
| void QApplication::syncX()
| {
| if (X11->display)
| XSync(X11->display, False);// don't discard
events
| }
|
|
| Seems we could use this function instead.
Did you test? It is not equal to the XSync I use.
False <-> True
I am quite certain the True is required.
And we still need the XEventsQueued.
--
Lgb
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bjønnes wrote: > | > Peter Kümmel <[EMAIL PROTECTED]> writes: > | > > | > | José Matos wrote: > | > | > On Thursday 24 May 2007 18:17:37 Peter Kümmel wrote: > | > | >> The event_1 patch gives better results on systems > | > | >> with a fast enough graphic card(?) but does not work > | > | >> an older systems. > | > | >> > | > | >> Jose feel free to do what you want. > | > | > > | > | > What is the outcome of your email exchange with Helge and Lars on > this > | > | > subject? > | > | > > | > | > This is an area where that looks like a landmine area, you step in > the wrong > | > | > place and ... > | > | > > | > | >> Peter > | > | > > | > | > | > | > | > | I'm pretty sure what's going on when my patch "eats" key events. > | > | Currently only pageup/pagedown key events are dropped. > | > | But JMark wants a more general approach so that also key gets > | > | dropped which are mapped by a binding to the scrolling keys. > | > | I don't know if Lars' patch is better. > | > > | > My patch works for all "key" variants. that is entered through > | > auto-keying. Basically all key events that we failt to handle because > | > auto-repeat is too fast are dropped. > | > > | > | And no keys will be dropped? > > If you go aab > then the b, might be dropped. I have not tested. > > But sure, quite a few will be dropped. (which is just what we > want if we are too slow to get them in.) > What if you have a slow system but you type with your 12 ;) fingers at a rate of 20 types per second. Then it is not a problem to type as sentence and then to wait a bit until all gets in. Or happens the dropping only to auto repeated keys? > | We could also put in your patch, as it is only a problem on Linux. > | Do you think we could use QApplication::synxX() instead of the X11 > | call? > > If I remember correctly, that call did the wrong thing. > -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Peter Kümmel wrote:
> | >
> | > And no keys will be dropped?
> | >
> | > We could also put in your patch, as it is only a problem on Linux.
> | > Do you think we could use QApplication::synxX() instead of the X11
> | > call?
> |
> | The Qt code:
> |
> http://websvn.kde.org/*checkout*/trunk/qt-copy/src/gui/kernel/qapplication_x11.cpp?content-type=text%2Fplain
> |
> | void QApplication::syncX()
> | {
> | if (X11->display)
> | XSync(X11->display, False);// don't discard
> events
> | }
> |
> |
> | Seems we could use this function instead.
>
> Did you test? It is not equal to the XSync I use.
No, I didn't.
> False <-> True
OK, I thought it was also False in your patch.
> I am quite certain the True is required.
http://tronche.com/gui/x/xlib/event-handling/XSync.html
yes, true enables discarding.
>
> And we still need the XEventsQueued.
>
--
Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel <[EMAIL PROTECTED]> writes: | > If you go aab | > then the b, might be dropped. I have not tested. | > | > But sure, quite a few will be dropped. (which is just what we | > want if we are too slow to get them in.) | > | | What if you have a slow system but you type with your 12 ;) | fingers at a rate of 20 types per second. Then it is not a problem | to type as sentence and then to wait a bit until all gets in. | | Or happens the dropping only to auto repeated keys? Only auto-repeated keys. -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | > If you go aab > | > then the b, might be dropped. I have not tested. > | > > | > But sure, quite a few will be dropped. (which is just what we > | > want if we are too slow to get them in.) > | > > | > | What if you have a slow system but you type with your 12 ;) > | fingers at a rate of 20 types per second. Then it is not a problem > | to type as sentence and then to wait a bit until all gets in. > | > | Or happens the dropping only to auto repeated keys? > > Only auto-repeated keys. OK, if you are really sure only auto-repeated keys will be dropped, I think your patch should go into RC1. -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Peter Kümmel <[EMAIL PROTECTED]> writes:
| >
| > | > If you go aab
| > | > then the b, might be dropped. I have not tested.
| > | >
| > | > But sure, quite a few will be dropped. (which is just what we
| > | > want if we are too slow to get them in.)
| > | >
| > |
| > | What if you have a slow system but you type with your 12 ;)
| > | fingers at a rate of 20 types per second. Then it is not a problem
| > | to type as sentence and then to wait a bit until all gets in.
| > |
| > | Or happens the dropping only to auto repeated keys?
| >
| > Only auto-repeated keys.
|
| OK, if you are really sure only auto-repeated keys will be dropped,
| I think your patch should go into RC1.
Yes, quite sure
+ if (e->isAutoRepeat()) {
+ ...
+ }
--
Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel <[EMAIL PROTECTED]> writes: | Peter Kümmel wrote: | >> | Or happens the dropping only to auto repeated keys? | >> | >> Only auto-repeated keys. | > | > OK, if you are really sure only auto-repeated keys will be dropped, | > I think your patch should go into RC1. | | BUT, I also had a Qt based patch which only discards auto repeated | keys, and Martin had a counter-argument, 'word completion': then put my queue of events back in and we can controll the events ourselves. qt does not give us acess to its event queue. btw. I think this nokia thingie is doing something dubious. And I am not sure we should care (much). -- Lgb
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: >> | Or happens the dropping only to auto repeated keys? >> >> Only auto-repeated keys. > > OK, if you are really sure only auto-repeated keys will be dropped, > I think your patch should go into RC1. BUT, I also had a Qt based patch which only discards auto repeated keys, and Martin had a counter-argument, 'word completion': http://marc.info/?l=lyx-devel=117947257615003=2 http://marc.info/?l=lyx-devel=117948429913972=2
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > Peter Kümmel <[EMAIL PROTECTED]> writes:
> | >
> | > | > If you go aab
> | > | > then the b, might be dropped. I have not tested.
> | > | >
> | > | > But sure, quite a few will be dropped. (which is just what we
> | > | > want if we are too slow to get them in.)
> | > | >
> | > |
> | > | What if you have a slow system but you type with your 12 ;)
> | > | fingers at a rate of 20 types per second. Then it is not a problem
> | > | to type as sentence and then to wait a bit until all gets in.
> | > |
> | > | Or happens the dropping only to auto repeated keys?
> | >
> | > Only auto-repeated keys.
> |
> | OK, if you are really sure only auto-repeated keys will be dropped,
> | I think your patch should go into RC1.
>
> Yes, quite sure
>
> + if (e->isAutoRepeat()) {
> + ...
> + }
>
Here I've also used isAutoRepeat()
http://marc.info/?l=lyx-devel=117938755501254=2
but we couldn't use it, maybe a Qt bug?
http://marc.info/?l=lyx-devel=117951666017572=2
So I should have a look again at this mail from Richard
http://marc.info/?l=lyx-devel=117952595711747=2
--
Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
On Thursday 31 May 2007 22:05:31 Lars Gullik Bjønnes wrote:
> Yes, quite sure
>
> + if (e->isAutoRepeat()) {
> + ...
> + }
Could you shove it in, please?
> --
> Lgb
--
José Abílio
Re: Scrolling lag in 1.5svn again, more details.
Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | Peter Kümmel wrote: > | >> | Or happens the dropping only to auto repeated keys? > | >> > | >> Only auto-repeated keys. > | > > | > OK, if you are really sure only auto-repeated keys will be dropped, > | > I think your patch should go into RC1. > | > | BUT, I also had a Qt based patch which only discards auto repeated > | keys, and Martin had a counter-argument, 'word completion': > > then put my queue of events back in and we can controll the events > ourselves. qt does not give us acess to its event queue. What is your "queue of events" ? > > btw. I think this nokia thingie is doing something dubious. And I am > not sure we should care (much). > Yes, it's a little bit exotic. -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
No ideas any more--also the last patch does not work (Helge's private reply). I've reverted the first patch, http://www.lyx.org/trac/changeset/18376 because it introduces this bug, http://marc.info/?l=lyx-develm=117944188219722w=2 detected by Dov. The event_1 patch gives better results on systems with a fast enough graphic card(?) but does not work an older systems. Jose feel free to do what you want. Peter
Re: Scrolling lag in 1.5svn again, more details.
No ideas any more--also the last patch does not work (Helge's private reply). I've reverted the first patch, http://www.lyx.org/trac/changeset/18376 because it introduces this bug, http://marc.info/?l=lyx-devel=117944188219722=2 detected by Dov. The event_1 patch gives better results on systems with a fast enough graphic card(?) but does not work an older systems. Jose feel free to do what you want. Peter
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: Peter Kümmel wrote: I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? event_2.patch works for me --- but then again event_1 did, too. Again, this is on linux. Scrolling appears to be fine (both with arrow keys and page-up and page-down, and with the scrollbars). I don't see any overshoot, either -- scrolling stops as soon as I stop pressing (or within a split-second). Can you try this with the machine being really busy? For example, test scrollbar scrolling with a maximized window, while the machine is busy compiling LyX? Or make it busy by running a simple script to make it waste time: File loadscript: ./loadscript This script will call itself in an endless loop, break it with ctrl+c when you are done testing. You can bring the load further up by running several of these, each in an xterm of its own. Or try delaying the display hardware by running some heavy animation/movie/3D-test on half the screen and do a lyx scrolltest on the other half. It is no surprise if a loaded test makes LyX _slow_, it still shouldn't overshoot though. Helge Hafting
Re: Scrolling lag in 1.5svn again, more details.
On Wed, May 23, 2007 at 12:13:16PM +0200, Helge Hafting wrote: Dov Feldstern wrote: Peter Kümmel wrote: I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? event_2.patch works for me --- but then again event_1 did, too. Again, this is on linux. Scrolling appears to be fine (both with arrow keys and page-up and page-down, and with the scrollbars). I don't see any overshoot, either -- scrolling stops as soon as I stop pressing (or within a split-second). Can you try this with the machine being really busy? For example, test scrollbar scrolling with a maximized window, while the machine is busy compiling LyX? Or make it busy by running a simple script to make it waste time: File loadscript: ./loadscript cat /dev/zero /dev/null gives a predictable constant load of 1. Andre'
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: Peter Kümmel wrote: I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? event_2.patch works for me --- but then again event_1 did, too. Again, this is on linux. Scrolling appears to be fine (both with arrow keys and page-up and page-down, and with the scrollbars). I don't see any overshoot, either -- scrolling stops as soon as I stop pressing (or within a split-second). Can you try this with the machine being really busy? For example, test scrollbar scrolling with a maximized window, while the machine is busy compiling LyX? Or make it busy by running a simple script to make it waste time: File loadscript: ./loadscript This script will call itself in an endless loop, break it with ctrl+c when you are done testing. You can bring the load further up by running several of these, each in an xterm of its own. Or try delaying the display hardware by running some heavy animation/movie/3D-test on half the screen and do a lyx scrolltest on the other half. It is no surprise if a loaded test makes LyX _slow_, it still shouldn't overshoot though. Helge Hafting
Re: Scrolling lag in 1.5svn again, more details.
On Wed, May 23, 2007 at 12:13:16PM +0200, Helge Hafting wrote: > Dov Feldstern wrote: > >Peter Kümmel wrote: > >> > >>I'm running out of ideas... > >>Is this patch better (the flush call is new)? > >>Or with processEvents instead of flush? > >> > > > >event_2.patch works for me --- but then again event_1 did, too. Again, > >this is on linux. Scrolling appears to be fine (both with arrow keys > >and page-up and page-down, and with the scrollbars). I don't see any > >overshoot, either -- scrolling stops as soon as I stop pressing (or > >within a split-second). > Can you try this with the machine being really busy? For example, > test scrollbar scrolling with a maximized window, while the machine > is busy compiling LyX? Or make it busy by running a simple > script to make it waste time: > > File loadscript: > ./loadscript cat /dev/zero > /dev/null gives a predictable constant load of 1. Andre'
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: Peter Kümmel wrote: I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? event_2.patch works for me --- but then again event_1 did, too. Again, this is on linux. Scrolling appears to be fine (both with arrow keys and page-up and page-down, and with the scrollbars). I don't see any overshoot, either -- scrolling stops as soon as I stop pressing (or within a split-second). The current svn code is not correct, even when this patch isn't perfect, should I apply it? Peter
Re: Scrolling lag in 1.5svn again, more details.
On Tuesday 22 May 2007 7:26:37 pm Peter Kümmel wrote: The current svn code is not correct, even when this patch isn't perfect, should I apply it? Could you get more people to test it, please? This is a sensitive area, just like walking on thin glass. :-) If by Friday you don't have any nay you can commit it, OK? Peter -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
José Matos wrote: On Tuesday 22 May 2007 7:26:37 pm Peter Kümmel wrote: The current svn code is not correct, even when this patch isn't perfect, should I apply it? Could you get more people to test it, please? This is a sensitive area, just like walking on thin glass. :-) If by Friday you don't have any nay you can commit it, OK? I could also live with reverting the last one, but with this patch at least on faster computers scrolling stops correctly. Maybe Helge could find the time to test my last patch. And even when it does not work on his system, it is better than the status before (when nobody finds a new bug) . Peter
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: > Peter Kümmel wrote: >> >> I'm running out of ideas... >> Is this patch better (the flush call is new)? >> Or with processEvents instead of flush? >> > > event_2.patch works for me --- but then again event_1 did, too. Again, > this is on linux. Scrolling appears to be fine (both with arrow keys and > page-up and page-down, and with the scrollbars). I don't see any > overshoot, either -- scrolling stops as soon as I stop pressing (or > within a split-second). > The current svn code is not correct, even when this patch isn't perfect, should I apply it? Peter
Re: Scrolling lag in 1.5svn again, more details.
On Tuesday 22 May 2007 7:26:37 pm Peter Kümmel wrote: > The current svn code is not correct, even when this patch isn't perfect, > should I apply it? Could you get more people to test it, please? This is a sensitive area, just like walking on thin glass. :-) If by Friday you don't have any nay you can commit it, OK? > Peter -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
José Matos wrote: > On Tuesday 22 May 2007 7:26:37 pm Peter Kümmel wrote: >> The current svn code is not correct, even when this patch isn't perfect, >> should I apply it? > > Could you get more people to test it, please? > > This is a sensitive area, just like walking on thin glass. :-) > > If by Friday you don't have any nay you can commit it, OK? I could also live with reverting the last one, but with this patch at least on faster computers scrolling stops correctly. Maybe Helge could find the time to test my last patch. And even when it does not work on his system, it is better than the status before (when nobody finds a new bug) . >> Peter
Re: Scrolling lag in 1.5svn again, more details.
Martin Vermeer wrote: On Sun, May 20, 2007 at 07:08:59PM +0200, Peter Kümmel wrote: Abdelrazak Younes wrote: ... OK, I've found a better solution ;) I had to test if it was worth to upgrade to 1GB ram. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Yes this is what it does. An it _is_ complicated. ;) But I've found a more Qt like and elegant solution. See attached patch, which should be much more readably. I've introduced two events which are only posted once to the event queue until the event is not processed. This also improves(?) the scrolling under Windows, see the comment in generateLyxScrollEvent. Yes, this looks _much_ better. Just as complicated, but very well designed ;-/ Fully agreed. I'll try to test it today or tomorrow. Abdel.
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Abdelrazak Younes wrote: Is this your only comment? Yes. Sorry, don't have the time to do much more. I thought I'd share my opinion ;-) Sorry, too - for my harsh reply. Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. OK, I've found a better solution ;) I had to test if it was worth to upgrade to 1GB ram. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Yes this is what it does. An it _is_ complicated. ;) But I've found a more Qt like and elegant solution. See attached patch, which should be much more readably. I've introduced two events which are only posted once to the event queue until the event is not processed. This also improves(?) the scrolling under Windows, see the comment in generateLyxScrollEvent. I checked out todays SVN, applied this patch, and compiled. Unfortunately, it doesn't help. At least not on linux. Scrolling a maximized userguide may still overshoot by several pages. Helge Hafting
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote: Martin Vermeer wrote: BTW what do you mean by 'input methods? Here I have a choice of virtual keyboard and handwriting recognition. How is that relevant? Input methods are used in the CJK world to help the writing. The technique is very similar to autocompletion method. Try '-dbg key' to see if it used. If yes, you should see things like preeditString = xxx and commitString = xxx. Maybe this is a similar problem. With today's svn, character feeding to LyX looked slow enough to perplex CJK (i.e. input methods) users. So far, I don't observe any loss of characters, but timing is as: (type one sentence) - (convert using IM) - (feed to lyx) - (wait 3 seconds)... (type a little long sentence) - (convert using IM) - (feed to lyx) - (wait 10 seconds)... I think this timing is long enough to interfere thinking of a writer. It happened on FreeBSD with fairly powerful machines. Somehow, it was not that bad on Windows (I observe *some* slowness but acceptable). Koji
Re: Scrolling lag in 1.5svn again, more details.
Helge Hafting wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Is this your only comment? Yes. Sorry, don't have the time to do much more. I thought I'd share my opinion ;-) Sorry, too - for my harsh reply. Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. OK, I've found a better solution ;) I had to test if it was worth to upgrade to 1GB ram. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Yes this is what it does. An it _is_ complicated. ;) But I've found a more Qt like and elegant solution. See attached patch, which should be much more readably. I've introduced two events which are only posted once to the event queue until the event is not processed. This also improves(?) the scrolling under Windows, see the comment in generateLyxScrollEvent. I checked out todays SVN, applied this patch, and compiled. Unfortunately, it doesn't help. At least not on linux. Scrolling a maximized userguide may still overshoot by several pages. Scrolling with what? Page down key? Scrollbar clicks? Could you please start with -dbg 8 and post the output? Helge Hafting -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Helge Hafting wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Is this your only comment?
Yes. Sorry, don't have the time to do much more. I thought I'd share my
opinion ;-)
Sorry, too - for my harsh reply.
Anyway I don't think there is a simpler solution, at least I will
not look for it, this bug has cost me already too much time.
OK, I've found a better solution ;)
I had to test if it was worth to upgrade to 1GB ram.
I can understand that. I was thinking of collecting the scroll events
and cancelling them if a scroll operation is still on-going but maybe
that's what your patch do. I only briefly looked at it and it _seems_
very complicated.
Yes this is what it does. An it _is_ complicated. ;)
But I've found a more Qt like and elegant solution.
See attached patch, which should be much more readably.
I've introduced two events which are only posted once
to the event queue until the event is not processed.
This also improves(?) the scrolling under Windows,
see the comment in generateLyxScrollEvent.
I checked out todays SVN, applied this patch, and compiled.
Unfortunately, it doesn't help. At least not on linux.
Scrolling a maximized userguide may still overshoot by several pages.
Helge Hafting
I'm running out of ideas...
Is this patch better (the flush call is new)?
Or with processEvents instead of flush?
--
Peter Kümmel
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18430)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,11 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(generateLyxScrollEvent()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(lyxScrollEvent()));
+
// disable context menu for the scrollbar
verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu);
@@ -211,6 +214,53 @@
}
+
+class LyxScrollEvent : public QEvent
+{
+public:
+ LyxScrollEvent() : QEvent(QEvent::Type(id))
+ {}
+ static const int id;
+ static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+const int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+ LyxKeyEvent(QKeyEvent * e) :
+ QKeyEvent(QEvent::Type(id), e-key(),
+ e-modifiers(), e-text(), e-isAutoRepeat(),
e-count())
+ {}
+ static const int id;
+ static bool locked;
+};
+
+const int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+ if (event-type() == LyxKeyEvent::id) {
+ lyxKeyEvent(dynamic_castLyxKeyEvent*(event));
+ LyxKeyEvent::locked = false;
+ return true;
+ } else if (event-type() == LyxScrollEvent::id) {
+ lyxScrollEvent();
+ LyxScrollEvent::locked = false;
+ return true;
+ } else {
+ return QAbstractScrollArea::event(event);
+ }
+}
+
+
void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int
scroll_line_step)
{
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,31 @@
}
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
{
scrollBufferView(verticalScrollBar()-sliderPosition());
+ QCoreApplication::flush();
}
+void GuiWorkArea::generateLyxScrollEvent()
+{
+ // This gives the old slow (the scroll bar couldn't follow the mouse)
+ // scrolling on Windows. Is it really better?
+ // Windows/Qt is here not as fast as X11
+ //lyxScrollEvent();return;
+
+ // multiple scroll events are merged into one
+ if (!LyxScrollEvent::locked) {
+ LyxScrollEvent::locked = true;
+ LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+ QCoreApplication::postEvent(this, scrollEvent);
+ LYXERR(Debug::GUI) scrolling: one event posted endl;
+ } else {
+ LYXERR(Debug::GUI) scrolling: waiting for processing last
scrolling event endl;
+ }
+}
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event-mimeData()-hasUrls())
@@ -389,13 +458,14 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
lines * verticalScrollBar()-singleStep());
- adjustViewWithScrollBar();
+
+ generateLyxScrollEvent();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ //
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? event_2.patch works for me --- but then again event_1 did, too. Again, this is on linux. Scrolling appears to be fine (both with arrow keys and page-up and page-down, and with the scrollbars). I don't see any overshoot, either -- scrolling stops as soon as I stop pressing (or within a split-second).
Re: Scrolling lag in 1.5svn again, more details.
Martin Vermeer wrote: On Sun, May 20, 2007 at 07:08:59PM +0200, Peter Kümmel wrote: Abdelrazak Younes wrote: ... OK, I've found a better solution ;) I had to test if it was worth to upgrade to 1GB ram. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Yes this is what it does. An it _is_ complicated. ;) But I've found a more Qt like and elegant solution. See attached patch, which should be much more readably. I've introduced two events which are only posted once to the event queue until the event is not processed. This also improves(?) the scrolling under Windows, see the comment in generateLyxScrollEvent. Yes, this looks _much_ better. Just as complicated, but very well designed ;-/ Fully agreed. I'll try to test it today or tomorrow. Abdel.
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Abdelrazak Younes wrote: Is this your only comment? Yes. Sorry, don't have the time to do much more. I thought I'd share my opinion ;-) Sorry, too - for my harsh reply. Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. OK, I've found a better solution ;) I had to test if it was worth to upgrade to 1GB ram. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Yes this is what it does. An it _is_ complicated. ;) But I've found a more Qt like and elegant solution. See attached patch, which should be much more readably. I've introduced two events which are only posted once to the event queue until the event is not processed. This also improves(?) the scrolling under Windows, see the comment in generateLyxScrollEvent. I checked out todays SVN, applied this patch, and compiled. Unfortunately, it doesn't help. At least not on linux. Scrolling a maximized userguide may still overshoot by several pages. Helge Hafting
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote: Martin Vermeer wrote: BTW what do you mean by 'input methods? Here I have a choice of virtual keyboard and handwriting recognition. How is that relevant? Input methods are used in the CJK world to help the writing. The technique is very similar to autocompletion method. Try '-dbg key' to see if it used. If yes, you should see things like "preeditString = xxx" and "commitString = xxx". Maybe this is a similar problem. With today's svn, character feeding to LyX looked slow enough to perplex CJK (i.e. input methods) users. So far, I don't observe any "loss" of characters, but timing is as: (type one sentence) -> (convert using IM) -> (feed to lyx) -> (wait 3 seconds)... (type a little long sentence) -> (convert using IM) -> (feed to lyx) -> (wait 10 seconds)... I think this timing is long enough to interfere thinking of a writer. It happened on FreeBSD with fairly powerful machines. Somehow, it was not that bad on Windows (I observe *some* slowness but acceptable). Koji
Re: Scrolling lag in 1.5svn again, more details.
Helge Hafting wrote: > Peter Kümmel wrote: >> Abdelrazak Younes wrote: >> Is this your only comment? >>> Yes. Sorry, don't have the time to do much more. I thought I'd share my >>> opinion ;-) >>> >> >> Sorry, too - for my harsh reply. >> >> Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. >> >> OK, I've found a better solution ;) >> I had to test if it was worth to upgrade to 1GB ram. >> >> >>> I can understand that. I was thinking of collecting the scroll events >>> and cancelling them if a scroll operation is still on-going but maybe >>> that's what your patch do. I only briefly looked at it and it _seems_ >>> very complicated. >>> >> >> Yes this is what it does. An it _is_ complicated. ;) >> >> But I've found a more Qt like and elegant solution. >> See attached patch, which should be much more readably. >> >> I've introduced two events which are only posted once >> to the event queue until the event is not processed. >> >> This also improves(?) the scrolling under Windows, >> see the comment in generateLyxScrollEvent. >> > I checked out todays SVN, applied this patch, and compiled. > Unfortunately, it doesn't help. At least not on linux. > Scrolling a maximized userguide may still overshoot by several pages. Scrolling with what? Page down key? Scrollbar clicks? Could you please start with -dbg 8 and post the output? > > Helge Hafting > -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Helge Hafting wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>
Is this your only comment?
>>> Yes. Sorry, don't have the time to do much more. I thought I'd share my
>>> opinion ;-)
>>>
>>
>> Sorry, too - for my harsh reply.
>>
>>
Anyway I don't think there is a simpler solution, at least I will
not look for it, this bug has cost me already too much time.
>>
>> OK, I've found a better solution ;)
>> I had to test if it was worth to upgrade to 1GB ram.
>>
>>
>>> I can understand that. I was thinking of collecting the scroll events
>>> and cancelling them if a scroll operation is still on-going but maybe
>>> that's what your patch do. I only briefly looked at it and it _seems_
>>> very complicated.
>>>
>>
>> Yes this is what it does. An it _is_ complicated. ;)
>>
>> But I've found a more Qt like and elegant solution.
>> See attached patch, which should be much more readably.
>>
>> I've introduced two events which are only posted once
>> to the event queue until the event is not processed.
>>
>> This also improves(?) the scrolling under Windows,
>> see the comment in generateLyxScrollEvent.
>>
> I checked out todays SVN, applied this patch, and compiled.
> Unfortunately, it doesn't help. At least not on linux.
> Scrolling a maximized userguide may still overshoot by several pages.
>
> Helge Hafting
>
I'm running out of ideas...
Is this patch better (the flush call is new)?
Or with processEvents instead of flush?
--
Peter Kümmel
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18430)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,11 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(generateLyxScrollEvent()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(lyxScrollEvent()));
+
// disable context menu for the scrollbar
verticalScrollBar()->setContextMenuPolicy(Qt::NoContextMenu);
@@ -211,6 +214,53 @@
}
+
+class LyxScrollEvent : public QEvent
+{
+public:
+ LyxScrollEvent() : QEvent(QEvent::Type(id))
+ {}
+ static const int id;
+ static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+const int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+ LyxKeyEvent(QKeyEvent * e) :
+ QKeyEvent(QEvent::Type(id), e->key(),
+ e->modifiers(), e->text(), e->isAutoRepeat(),
e->count())
+ {}
+ static const int id;
+ static bool locked;
+};
+
+const int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+ if (event->type() == LyxKeyEvent::id) {
+ lyxKeyEvent(dynamic_cast(event));
+ LyxKeyEvent::locked = false;
+ return true;
+ } else if (event->type() == LyxScrollEvent::id) {
+ lyxScrollEvent();
+ LyxScrollEvent::locked = false;
+ return true;
+ } else {
+ return QAbstractScrollArea::event(event);
+ }
+}
+
+
void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int
scroll_line_step)
{
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,31 @@
}
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
{
scrollBufferView(verticalScrollBar()->sliderPosition());
+ QCoreApplication::flush();
}
+void GuiWorkArea::generateLyxScrollEvent()
+{
+ // This gives the old slow (the scroll bar couldn't follow the mouse)
+ // scrolling on Windows. Is it really better?
+ // Windows/Qt is here not as fast as X11
+ //lyxScrollEvent();return;
+
+ // multiple scroll events are merged into one
+ if (!LyxScrollEvent::locked) {
+ LyxScrollEvent::locked = true;
+ LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+ QCoreApplication::postEvent(this, scrollEvent);
+ LYXERR(Debug::GUI) << "scrolling: one event posted" << endl;
+ } else {
+ LYXERR(Debug::GUI) << "scrolling: waiting for processing last
scrolling event" << endl;
+ }
+}
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event->mimeData()->hasUrls())
@@ -389,13 +458,14 @@
int const lines = qApp->wheelScrollLines() * e->delta() / 120;
verticalScrollBar()->setValue(verticalScrollBar()->value() -
lines * verticalScrollBar()->singleStep());
- adjustViewWithScrollBar();
+
+ generateLyxScrollEvent();
}
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? event_2.patch works for me --- but then again event_1 did, too. Again, this is on linux. Scrolling appears to be fine (both with arrow keys and page-up and page-down, and with the scrollbars). I don't see any overshoot, either -- scrolling stops as soon as I stop pressing (or within a split-second).
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: Next try. To see how it works change the event_delay_ms variable in the constructor to 3000 and use -dbg 12. This looks way too complicated Peter. There must be a simpler solution. Abdel. Is this your only comment? Yes. Sorry, don't have the time to do much more. I thought I'd share my opinion ;-) Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Dimitri from Trolltech wrote on a similar problem: You'll need to maintain flags, QTimers waiting N milliseconds and other data to achive that. There's no equivalent information maintained by Qt. http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html Hope this has convinced you. ;) I trust you. Abdel.
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote:
Is this your only comment?
Yes. Sorry, don't have the time to do much more. I thought I'd share my
opinion ;-)
Sorry, too - for my harsh reply.
Anyway I don't think there is a simpler solution, at least I will
not look for it, this bug has cost me already too much time.
OK, I've found a better solution ;)
I had to test if it was worth to upgrade to 1GB ram.
I can understand that. I was thinking of collecting the scroll events
and cancelling them if a scroll operation is still on-going but maybe
that's what your patch do. I only briefly looked at it and it _seems_
very complicated.
Yes this is what it does. An it _is_ complicated. ;)
But I've found a more Qt like and elegant solution.
See attached patch, which should be much more readably.
I've introduced two events which are only posted once
to the event queue until the event is not processed.
This also improves(?) the scrolling under Windows,
see the comment in generateLyxScrollEvent.
Dimitri from Trolltech wrote on a similar problem:
You'll need to maintain flags, QTimers waiting N milliseconds and other
data to achive that. There's no equivalent information maintained by Qt.
http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html
Hope this has convinced you. ;)
I trust you.
But the patch needs still more testing.
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18430)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,11 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(generateLyxScrollEvent()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(lyxScrollEvent()));
+
// disable context menu for the scrollbar
verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu);
@@ -211,6 +214,53 @@
}
+
+class LyxScrollEvent : public QEvent
+{
+public:
+ LyxScrollEvent() : QEvent(QEvent::Type(id))
+ {}
+ static int id;
+ static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+ LyxKeyEvent(QKeyEvent * e) :
+ QKeyEvent(QEvent::Type(id), e-key(),
+ e-modifiers(), e-text(), e-isAutoRepeat(),
e-count())
+ {}
+ static int id;
+ static bool locked;
+};
+
+int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+ if (event-type() == LyxKeyEvent::id) {
+ lyxKeyEvent(dynamic_castLyxKeyEvent*(event));
+ LyxKeyEvent::locked = false;
+ return true;
+ } else if (event-type() == LyxScrollEvent::id) {
+ lyxScrollEvent();
+ LyxScrollEvent::locked = false;
+ return true;
+ } else {
+ return QAbstractScrollArea::event(event);
+ }
+}
+
+
void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int
scroll_line_step)
{
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,30 @@
}
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
{
scrollBufferView(verticalScrollBar()-sliderPosition());
}
+void GuiWorkArea::generateLyxScrollEvent()
+{
+ // This gives the old slow (the scroll bar couldn't follow the mouse)
+ // scrolling on Windows. Is it really better?
+ // Windows/Qt is here not as fast as X11
+ //lyxScrollEvent();return;
+
+ // multiple scroll events are merged into one
+ if (!LyxScrollEvent::locked) {
+ LyxScrollEvent::locked = true;
+ LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+ QCoreApplication::postEvent(this, scrollEvent);
+ LYXERR(Debug::GUI) scrolling: one event posted endl;
+ } else {
+ LYXERR(Debug::GUI) scrolling: waiting for processing last
scrolling event endl;
+ }
+}
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event-mimeData()-hasUrls())
@@ -389,13 +457,14 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
lines * verticalScrollBar()-singleStep());
- adjustViewWithScrollBar();
+
+ generateLyxScrollEvent();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ // Set things off to generate the _next_ 'pseudo' event.
if (synthetic_mouse_event_.restart_timeout)
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: Peter Kümmel wrote: On slow/loaded systems the last patch floods the event queue with timer events instead of key/scroll events. I hope attached patch will now really fix the problem. Peter This works for me (timer_scroll_4.patch) --- at least for what I'm testing, namely, cursor movement by holding down keys. Thanks Dov, good to hear, then I assume that the next patch will also work: event_1.patch. Peter
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Dov Feldstern wrote: Peter Kümmel wrote: On slow/loaded systems the last patch floods the event queue with timer events instead of key/scroll events. I hope attached patch will now really fix the problem. Peter This works for me (timer_scroll_4.patch) --- at least for what I'm testing, namely, cursor movement by holding down keys. Thanks Dov, good to hear, then I assume that the next patch will also work: event_1.patch. Peter Yes, it does. :) It seems perhaps to respond even better than the previous patch, though that may only be my imagination ;) . I'll keep this in for now, I'll let you know if I run into any trouble. Dov
Re: Scrolling lag in 1.5svn again, more details.
On Sun, May 20, 2007 at 07:08:59PM +0200, Peter Kümmel wrote: Abdelrazak Younes wrote: ... OK, I've found a better solution ;) I had to test if it was worth to upgrade to 1GB ram. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Yes this is what it does. An it _is_ complicated. ;) But I've found a more Qt like and elegant solution. See attached patch, which should be much more readably. I've introduced two events which are only posted once to the event queue until the event is not processed. This also improves(?) the scrolling under Windows, see the comment in generateLyxScrollEvent. Yes, this looks _much_ better. Just as complicated, but very well designed ;-/ - Martin
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: Next try. To see how it works change the event_delay_ms variable in the constructor to 3000 and use -dbg 12. This looks way too complicated Peter. There must be a simpler solution. Abdel. Is this your only comment? Yes. Sorry, don't have the time to do much more. I thought I'd share my opinion ;-) Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. I can understand that. I was thinking of collecting the scroll events and cancelling them if a scroll operation is still on-going but maybe that's what your patch do. I only briefly looked at it and it _seems_ very complicated. Dimitri from Trolltech wrote on a similar problem: "You'll need to maintain flags, QTimers waiting N milliseconds and other data to achive that. There's no equivalent information maintained by Qt." http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html Hope this has convinced you. ;) I trust you. Abdel.
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote:
>> Is this your only comment?
>
> Yes. Sorry, don't have the time to do much more. I thought I'd share my
> opinion ;-)
Sorry, too - for my harsh reply.
>
>>
>> Anyway I don't think there is a simpler solution, at least I will
>> not look for it, this bug has cost me already too much time.
OK, I've found a better solution ;)
I had to test if it was worth to upgrade to 1GB ram.
>
> I can understand that. I was thinking of collecting the scroll events
> and cancelling them if a scroll operation is still on-going but maybe
> that's what your patch do. I only briefly looked at it and it _seems_
> very complicated.
Yes this is what it does. An it _is_ complicated. ;)
But I've found a more Qt like and elegant solution.
See attached patch, which should be much more readably.
I've introduced two events which are only posted once
to the event queue until the event is not processed.
This also improves(?) the scrolling under Windows,
see the comment in generateLyxScrollEvent.
>
>>
>> Dimitri from Trolltech wrote on a similar problem:
>>
>> "You'll need to maintain flags, QTimers waiting N milliseconds and other
>> data to achive that. There's no equivalent information maintained by Qt."
>>
>> http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html
>>
>>
>> Hope this has convinced you. ;)
>
> I trust you.
But the patch needs still more testing.
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18430)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,11 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(generateLyxScrollEvent()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(lyxScrollEvent()));
+
// disable context menu for the scrollbar
verticalScrollBar()->setContextMenuPolicy(Qt::NoContextMenu);
@@ -211,6 +214,53 @@
}
+
+class LyxScrollEvent : public QEvent
+{
+public:
+ LyxScrollEvent() : QEvent(QEvent::Type(id))
+ {}
+ static int id;
+ static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+ LyxKeyEvent(QKeyEvent * e) :
+ QKeyEvent(QEvent::Type(id), e->key(),
+ e->modifiers(), e->text(), e->isAutoRepeat(),
e->count())
+ {}
+ static int id;
+ static bool locked;
+};
+
+int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+ if (event->type() == LyxKeyEvent::id) {
+ lyxKeyEvent(dynamic_cast(event));
+ LyxKeyEvent::locked = false;
+ return true;
+ } else if (event->type() == LyxScrollEvent::id) {
+ lyxScrollEvent();
+ LyxScrollEvent::locked = false;
+ return true;
+ } else {
+ return QAbstractScrollArea::event(event);
+ }
+}
+
+
void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int
scroll_line_step)
{
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,30 @@
}
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
{
scrollBufferView(verticalScrollBar()->sliderPosition());
}
+void GuiWorkArea::generateLyxScrollEvent()
+{
+ // This gives the old slow (the scroll bar couldn't follow the mouse)
+ // scrolling on Windows. Is it really better?
+ // Windows/Qt is here not as fast as X11
+ //lyxScrollEvent();return;
+
+ // multiple scroll events are merged into one
+ if (!LyxScrollEvent::locked) {
+ LyxScrollEvent::locked = true;
+ LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+ QCoreApplication::postEvent(this, scrollEvent);
+ LYXERR(Debug::GUI) << "scrolling: one event posted" << endl;
+ } else {
+ LYXERR(Debug::GUI) << "scrolling: waiting for processing last
scrolling event" << endl;
+ }
+}
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event->mimeData()->hasUrls())
@@ -389,13 +457,14 @@
int const lines = qApp->wheelScrollLines() * e->delta() / 120;
verticalScrollBar()->setValue(verticalScrollBar()->value() -
lines * verticalScrollBar()->singleStep());
- adjustViewWithScrollBar();
+
+ generateLyxScrollEvent();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ // Set things off to generate the _next_ 'pseudo'
Re: Scrolling lag in 1.5svn again, more details.
Dov Feldstern wrote: > Peter Kümmel wrote: >> >> On slow/loaded systems the last patch floods the >> event queue with timer events instead of key/scroll events. >> I hope attached patch will now really fix the problem. >> >> Peter >> > > This works for me (timer_scroll_4.patch) --- at least for what I'm > testing, namely, cursor movement by holding down keys. > Thanks Dov, good to hear, then I assume that the next patch will also work: event_1.patch. Peter
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Dov Feldstern wrote: Peter Kümmel wrote: On slow/loaded systems the last patch floods the event queue with timer events instead of key/scroll events. I hope attached patch will now really fix the problem. Peter This works for me (timer_scroll_4.patch) --- at least for what I'm testing, namely, cursor movement by holding down keys. Thanks Dov, good to hear, then I assume that the next patch will also work: event_1.patch. Peter Yes, it does. :) It seems perhaps to respond even better than the previous patch, though that may only be my imagination ;) . I'll keep this in for now, I'll let you know if I run into any trouble. Dov
Re: Scrolling lag in 1.5svn again, more details.
On Sun, May 20, 2007 at 07:08:59PM +0200, Peter Kümmel wrote: > Abdelrazak Younes wrote: ... > OK, I've found a better solution ;) > I had to test if it was worth to upgrade to 1GB ram. > > > > > I can understand that. I was thinking of collecting the scroll events > > and cancelling them if a scroll operation is still on-going but maybe > > that's what your patch do. I only briefly looked at it and it _seems_ > > very complicated. > > Yes this is what it does. An it _is_ complicated. ;) > > But I've found a more Qt like and elegant solution. > See attached patch, which should be much more readably. > > I've introduced two events which are only posted once > to the event queue until the event is not processed. > > This also improves(?) the scrolling under Windows, > see the comment in generateLyxScrollEvent. Yes, this looks _much_ better. Just as complicated, but very well designed ;-/ - Martin
Re: Scrolling lag in 1.5svn again, more details.
On Fri, May 18, 2007 at 08:12:33AM +0200, Peter Kümmel wrote: I also realized this while working on this bug. So I dropped my first patches and now use isAutoRepeated in the committed patch, by this a keystroke produced by a user will never get lost. All typed keystrokes are in the event queue even when the user types with 1 key/sec. Sounds good. Please make sure this gets extensively tested on different platforms. Andre'
Re: Scrolling lag in 1.5svn again, more details.
On Fri, May 18, 2007 at 08:43:12AM +0200, Peter Kümmel wrote: Andre Poenitz wrote: === --- src/frontends/qt4/GuiWorkArea.cpp (revision 18380) +++ src/frontends/qt4/GuiWorkArea.cpp (working copy) @@ -161,7 +161,7 @@ GuiWorkArea::GuiWorkArea(int w, int h, int id, LyXView lyx_view) : WorkArea(id, lyx_view), need_resize_(false), schedule_redraw_(false), -preedit_lines_(1) +preedit_lines_(1), delayed_scrollbar_sync(*new QTimer(this)) Do you need an explicit timer object? There's QObject::startTimer() and QObject::timerEvent()... Ah, didn't know there is already a timer when being a QObject. Will have a look at it. Index: src/frontends/qt4/GuiWorkArea.h === --- src/frontends/qt4/GuiWorkArea.h(revision 18380) +++ src/frontends/qt4/GuiWorkArea.h(working copy) @@ -156,6 +156,14 @@ /// timer to limit triple clicks void doubleClickTimeout(); +private Q_SLOTS: + /// process vertical scroll bar event + void verticalScrollBarActionTriggered(int action); + /// + void verticalScrollBarSliderPressed(); + /// + void verticalScrollBarSliderReleased(); + private: /// The slot connected to SyntheticMouseEvent::timeout. void generateSyntheticMouseEvent(); @@ -177,6 +185,8 @@ bool schedule_redraw_; /// int preedit_lines_; + /// + QTimer delayed_scrollbar_sync; A _reference_? Why? At could forward declare QTimer, but isn't that important. This would be possible with a pointer, to. What you wrote works indeed, but I am not sure that it is clear to everybody glancing over the code _why_ it works. Andre'
Re: Scrolling lag in 1.5svn again, more details.
Andre Poenitz wrote: On Fri, May 18, 2007 at 08:12:33AM +0200, Peter Kümmel wrote: I also realized this while working on this bug. So I dropped my first patches and now use isAutoRepeated in the committed patch, by this a keystroke produced by a user will never get lost. All typed keystrokes are in the event queue even when the user types with 1 key/sec. Sounds good. Please make sure this gets extensively tested on different platforms. Andre' Maybe it is better when you start reading at the end of the thread, ;) both patches, the committed and the proposed, are obsolete. -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Andre Poenitz wrote: On Fri, May 18, 2007 at 08:43:12AM +0200, Peter Kümmel wrote: Andre Poenitz wrote: === --- src/frontends/qt4/GuiWorkArea.cpp (revision 18380) +++ src/frontends/qt4/GuiWorkArea.cpp (working copy) @@ -161,7 +161,7 @@ GuiWorkArea::GuiWorkArea(int w, int h, int id, LyXView lyx_view) : WorkArea(id, lyx_view), need_resize_(false), schedule_redraw_(false), -preedit_lines_(1) +preedit_lines_(1), delayed_scrollbar_sync(*new QTimer(this)) Do you need an explicit timer object? There's QObject::startTimer() and QObject::timerEvent()... Ah, didn't know there is already a timer when being a QObject. Will have a look at it. Index: src/frontends/qt4/GuiWorkArea.h === --- src/frontends/qt4/GuiWorkArea.h(revision 18380) +++ src/frontends/qt4/GuiWorkArea.h(working copy) @@ -156,6 +156,14 @@ /// timer to limit triple clicks void doubleClickTimeout(); +private Q_SLOTS: + /// process vertical scroll bar event + void verticalScrollBarActionTriggered(int action); + /// + void verticalScrollBarSliderPressed(); + /// + void verticalScrollBarSliderReleased(); + private: /// The slot connected to SyntheticMouseEvent::timeout. void generateSyntheticMouseEvent(); @@ -177,6 +185,8 @@ bool schedule_redraw_; /// int preedit_lines_; + /// + QTimer delayed_scrollbar_sync; A _reference_? Why? At could forward declare QTimer, but isn't that important. This would be possible with a pointer, to. But then you are not forced by the compiler to initialize it, because of this a prefer a reference, it's shorter in declaring and using than *const. What you wrote works indeed, but I am not sure that it is clear to everybody glancing over the code _why_ it works. I'm preparing a patch which works, and where I know why. Andre' -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Next try. To see how it works change the event_delay_ms
variable in the constructor to 3000 and use -dbg 12.
Please test if scrolling works when
- moving the slider with the mouse
- clicking in the scroll bar
- pressing page up/down keys
- arrow keys
- arrow buttons on the scroll bar
- using the mouse wheel (use the mouse up side
down and move it on the table)
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18398)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,29 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(verticalScrollBarActionTriggered()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(verticalScrollBarSliderReleased()));
+ // We circumvent the event queue for scroll events.
+ // This avoids scrolling after the user has stopped
+ // scrolling, but scrolling proceeds because the
+ // event queue is full of scroll events.
+ // We trigger the scrolling by a timer which we
+ // could stop at any time (we can't clean the
+ // event queue from scrolling events)
+ int event_delay_ms = 30;
+ delayed_scrollbar_sync.setInterval(event_delay_ms);
+ delayed_scrollbar_sync.setSingleShot(true);
+ QObject::connect(delayed_scrollbar_sync, SIGNAL(timeout()),
+ this, SLOT(adjustViewWithScrollBar()));
+
+ delayed_key_event.setInterval(event_delay_ms);
+ delayed_key_event.setSingleShot(true);
+ QObject::connect(delayed_key_event, SIGNAL(timeout()),
+ this, SLOT(processDelayedKeys()));
+
+
// disable context menu for the scrollbar
verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu);
@@ -237,6 +258,24 @@
}
+void GuiWorkArea::verticalScrollBarActionTriggered()
+{
+ // multiple scroll events are merged into one
+ if (!delayed_scrollbar_sync.isActive()) {
+ delayed_scrollbar_sync.start();
+ } else {
+ LYXERR(Debug::GUI)
GuiWorkArea::verticalScrollBarActionTriggered event ignored endl;
+ }
+}
+
+void GuiWorkArea::verticalScrollBarSliderReleased()
+{
+ delayed_scrollbar_sync.stop();
+ // finally adjust the scrollbar
+ adjustViewWithScrollBar();
+}
+
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event-mimeData()-hasUrls())
@@ -389,13 +428,13 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
lines * verticalScrollBar()-singleStep());
- adjustViewWithScrollBar();
+ verticalScrollBarActionTriggered();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ // Set things off to generate the _next_ 'pseudo' event.
if (synthetic_mouse_event_.restart_timeout)
synthetic_mouse_event_.timeout.start();
@@ -412,14 +451,45 @@
}
+void GuiWorkArea::processDelayedKeys()
+{
+ for (size_t i = 0; i delayed_keys.size(); ++i) {
+ boost::shared_ptrQKeySymbol sym(delayed_keys[i].sym);
+ processKeySym(sym, q_key_state(delayed_keys[i].mod));
+ }
+ delayed_keys.clear();
+}
+
+
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
- // do nothing if there are other events
- // (the auto repeated events come too fast)
- if (e-isAutoRepeat() QCoreApplication::hasPendingEvents()) {
- LYXERR(Debug::KEY)
-BOOST_CURRENT_FUNCTION endl
-key ignored endl;
+ // add here all keys which should be delayed
+ static const int delayed_keys_val = Qt::Key_PageDown | Qt::Key_PageUp;
+
+ if (e-key() delayed_keys_val) {
+ LYXERR(Debug::KEY) BOOST_CURRENT_FUNCTION endl
+key deleayed, delayed_keys.size() key(s)
in buffer endl;
+
+ // eat repeated keys
+ bool repeated = false;
+ for (size_t i = 0; i delayed_keys.size(); ++i) {
+ if (delayed_keys[i].sym-key() == e-key()
+ delayed_keys[i].mod == e-modifiers()) {
+ repeated = true;
+ break;
+ }
+ }
+ if(!repeated) {
+ QKeySymbol* sym = new QKeySymbol;
+ sym-set(e);
+ key_info ki;
+ ki.sym = sym;
+ ki.mod = e-modifiers();
+ delayed_keys.push_back(ki);
+ if
Re: Scrolling lag in 1.5svn again, more details.
+#include set
not needed will remove it
class QWidget;
+ ///
+ QTimer delayed_scrollbar_sync;
+ ///
+ QTimer delayed_key_event;
+ struct key_info { QKeySymbol* sym; Qt::KeyboardModifiers mod; };
+ std::vectorkey_info delayed_keys;
};
Andre, any tips how to format?
--
Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote:
Next try. To see how it works change the event_delay_ms
variable in the constructor to 3000 and use -dbg 12.
Please test if scrolling works when
- moving the slider with the mouse
- clicking in the scroll bar
- pressing page up/down keys
- arrow keys
- arrow buttons on the scroll bar
- using the mouse wheel (use the mouse up side
down and move it on the table)
Peter
On slow/loaded systems the last patch floods the
event queue with timer events instead of key/scroll events.
I hope attached patch will now really fix the problem.
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18398)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -190,8 +190,31 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(verticalScrollBarActionTriggered()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(verticalScrollBarSliderReleased()));
+ // We circumvent the event queue for scroll events.
+ // This avoids scrolling after the user has stopped
+ // scrolling, but scrolling proceeds because the
+ // event queue is full of scroll events.
+ // We trigger the scrolling by a timer which we
+ // could stop at any time (we can't clean the
+ // event queue from scrolling events)
+ int event_delay_ms = 30;
+ waiting_for_scrolling = false;
+ delayed_scrolling_timer.setInterval(event_delay_ms);
+ delayed_scrolling_timer.setSingleShot(true);
+ QObject::connect(delayed_scrolling_timer, SIGNAL(timeout()),
+ this, SLOT(adjustViewWithScrollBar()));
+
+ waiting_for_key_processing = false;
+ delayed_key_timer.setInterval(event_delay_ms);
+ delayed_key_timer.setSingleShot(true);
+ QObject::connect(delayed_key_timer, SIGNAL(timeout()),
+ this, SLOT(processDelayedKeys()));
+
+
// disable context menu for the scrollbar
verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu);
@@ -234,9 +257,33 @@
void GuiWorkArea::adjustViewWithScrollBar(int)
{
scrollBufferView(verticalScrollBar()-sliderPosition());
+ waiting_for_scrolling = false;
+ LYXERR(Debug::GUI) delayed_scrolling_timer shot done endl;
}
+void GuiWorkArea::verticalScrollBarActionTriggered()
+{
+ // multiple scroll events are merged into one
+ if (!waiting_for_scrolling) {
+ waiting_for_scrolling = true;
+ if (!delayed_scrolling_timer.isActive()) {
+ LYXERR(Debug::GUI) delayed_scrolling_timer started
endl;
+ delayed_scrolling_timer.start();
+ }
+ } else {
+ LYXERR(Debug::GUI)
GuiWorkArea::verticalScrollBarActionTriggered event ignored endl;
+ }
+}
+
+void GuiWorkArea::verticalScrollBarSliderReleased()
+{
+ delayed_scrolling_timer.stop();
+ // finally adjust the scrollbar
+ adjustViewWithScrollBar();
+}
+
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event-mimeData()-hasUrls())
@@ -389,13 +436,13 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
lines * verticalScrollBar()-singleStep());
- adjustViewWithScrollBar();
+ verticalScrollBarActionTriggered();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ // Set things off to generate the _next_ 'pseudo' event.
if (synthetic_mouse_event_.restart_timeout)
synthetic_mouse_event_.timeout.start();
@@ -412,14 +459,51 @@
}
+void GuiWorkArea::processDelayedKeys()
+{
+ for (size_t i = 0; i delayed_keys.size(); ++i) {
+ boost::shared_ptrQKeySymbol sym(delayed_keys[i].sym);
+ processKeySym(sym, q_key_state(delayed_keys[i].mod));
+ }
+ delayed_keys.clear();
+ LYXERR(Debug::KEY) delayed_key_timer shot done endl;
+ waiting_for_key_processing = false;
+}
+
+
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
- // do nothing if there are other events
- // (the auto repeated events come too fast)
- if (e-isAutoRepeat() QCoreApplication::hasPendingEvents()) {
- LYXERR(Debug::KEY)
-BOOST_CURRENT_FUNCTION endl
-key ignored endl;
+ // add here all keys which should be delayed
+ static const int delayed_keys_val = Qt::Key_PageDown | Qt::Key_PageUp;
+
+ if (e-key() delayed_keys_val) {
+ LYXERR(Debug::KEY) BOOST_CURRENT_FUNCTION endl
Re: Scrolling lag in 1.5svn again, more details.
On Sat, May 19, 2007 at 10:53:39AM +0200, Peter Kümmel wrote:
+#include set
not needed will remove it
class QWidget;
+ ///
+ QTimer delayed_scrollbar_sync;
+ ///
+ QTimer delayed_key_event;
+ struct key_info { QKeySymbol* sym; Qt::KeyboardModifiers mod; };
+ std::vectorkey_info delayed_keys;
};
Andre, any tips how to format?
QTimer delayed_key_event;
struct KeyInfo { QKeySymbol * sym; Qt::KeyboardModifiers mod; };
std::vectorKeyInfo delayed_keys;
or
/// ...
QTimer delayed_key_event;
/// ...
struct KeyInfo {
[/// ...]
QKeySymbol * sym;
[/// ...]
Qt::KeyboardModifiers mod;
};
/// ...
std::vectorKeyInfo delayed_keys;
would be fine with me.
Andre'
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Next try. To see how it works change the event_delay_ms variable in the constructor to 3000 and use -dbg 12. This looks way too complicated Peter. There must be a simpler solution. Abdel.
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote: Peter Kümmel wrote: Next try. To see how it works change the event_delay_ms variable in the constructor to 3000 and use -dbg 12. This looks way too complicated Peter. There must be a simpler solution. Abdel. Is this your only comment? Anyway I don't think there is a simpler solution, at least I will not look for it, this bug has cost me already too much time. Dimitri from Trolltech wrote on a similar problem: You'll need to maintain flags, QTimers waiting N milliseconds and other data to achive that. There's no equivalent information maintained by Qt. http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html Hope this has convinced you. ;) -- Peter Kümmel
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Next try. To see how it works change the event_delay_ms
variable in the constructor to 3000 and use -dbg 12.
This looks way too complicated Peter. There must be a simpler solution.
Abdel.
You could start with some like the attached patch (does not work on Linux)
or with an event filter as mentioned in the Trolltech list thread.
--
Peter Kümmel
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (revision 18416)
+++ src/frontends/qt4/GuiWorkArea.cpp (working copy)
@@ -161,7 +161,8 @@
GuiWorkArea::GuiWorkArea(int w, int h, int id, LyXView lyx_view)
: WorkArea(id, lyx_view), need_resize_(false), schedule_redraw_(false),
- preedit_lines_(1)
+ preedit_lines_(1), waiting_for_key_processing(false),
+ waiting_for_scrolling(false)
{
screen_ = QPixmap(viewport()-width(), viewport()-height());
cursor_ = new frontend::CursorWidget();
@@ -190,8 +191,21 @@
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
- this, SLOT(adjustViewWithScrollBar(int)));
+ this, SLOT(verticalScrollBarActionTriggered()));
+ QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+ this, SLOT(verticalScrollBarSliderReleased()));
+ // We circumvent the event queue for scroll events.
+ // This avoids scrolling after the user has stopped
+ // scrolling, but scrolling proceeds because the
+ // event queue is full of scroll events.
+ QObject::connect(this, SIGNAL(updateScrollBar()),
+ this, SLOT(adjustViewWithScrollBar()));
+ QObject::connect(this, SIGNAL(processKeySignal(QKeyEvent*)),
+ this, SLOT(processKey(QKeyEvent*)));
+
+
+
// disable context menu for the scrollbar
verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu);
@@ -234,9 +248,32 @@
void GuiWorkArea::adjustViewWithScrollBar(int)
{
scrollBufferView(verticalScrollBar()-sliderPosition());
+ waiting_for_scrolling = false;
+ LYXERR(Debug::GUI) BOOST_CURRENT_FUNCTION
+: delayed scrolling done endl;
}
+void GuiWorkArea::verticalScrollBarActionTriggered()
+{
+ // multiple scroll events are merged into one
+ if (!waiting_for_scrolling) {
+ waiting_for_scrolling = true;
+ // emit signal
+ updateScrollBar();
+ } else {
+ LYXERR(Debug::GUI) BOOST_CURRENT_FUNCTION
+: delay scrolling endl;
+ }
+}
+
+void GuiWorkArea::verticalScrollBarSliderReleased()
+{
+ // finally adjust the scrollbar
+ adjustViewWithScrollBar();
+}
+
+
void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
{
if (event-mimeData()-hasUrls())
@@ -389,13 +426,13 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
lines * verticalScrollBar()-singleStep());
- adjustViewWithScrollBar();
+ verticalScrollBarActionTriggered();
}
void GuiWorkArea::generateSyntheticMouseEvent()
{
-// Set things off to generate the _next_ 'pseudo' event.
+ // Set things off to generate the _next_ 'pseudo' event.
if (synthetic_mouse_event_.restart_timeout)
synthetic_mouse_event_.timeout.start();
@@ -412,14 +449,32 @@
}
+void GuiWorkArea::processKey(QKeyEvent * e)
+{
+ boost::shared_ptrQKeySymbol sym(new QKeySymbol);
+ sym-set(e);
+ processKeySym(sym, q_key_state(e-modifiers()));
+ waiting_for_key_processing = false;
+ LYXERR(Debug::GUI) BOOST_CURRENT_FUNCTION
+: delayed key processing done endl;
+}
+
+
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
- // do nothing if there are other events
- // (the auto repeated events come too fast)
- if (e-isAutoRepeat() QCoreApplication::hasPendingEvents()) {
- LYXERR(Debug::KEY)
-BOOST_CURRENT_FUNCTION endl
-key ignored endl;
+ // add here all keys which should be delayed
+ static const int delayed_keys = Qt::Key_PageDown | Qt::Key_PageUp;
+
+ if (e-key() delayed_keys) {
+ LYXERR(Debug::GUI) BOOST_CURRENT_FUNCTION
+: delay key processing endl;
+ if (!waiting_for_key_processing) {
+ waiting_for_key_processing = true;
+ // emit signal
+ e-accept();
+ processKey(e);
+ return;
+ }
e-ignore();
return;
}
Index: src/frontends/qt4/GuiWorkArea.h
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Dov Feldstern wrote: The truth is, I don't know that this is directly related to the machine on which it's running. My machine is quite powerful --- it's a Pentium IV 3.0 GHz; and I don't see any jump in the system load when I start scrolling, either: not when I start and the cursor is still zooming along, nor when it suddenly becomes saturated with events and stops moving... Very good, it is not due to the system performance. What is your setup? Linux, Qt4.2? Seems we are now in the depth of cross platform event handling. Peter I'm running in Linux, debian unstable (actually inside a linux-vserver, I haven't found that to slow things down appreciably, though), Qt 4.2.1.
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: On slow/loaded systems the last patch floods the event queue with timer events instead of key/scroll events. I hope attached patch will now really fix the problem. Peter This works for me (timer_scroll_4.patch) --- at least for what I'm testing, namely, cursor movement by holding down keys.
Re: Scrolling lag in 1.5svn again, more details.
On Fri, May 18, 2007 at 08:12:33AM +0200, Peter Kümmel wrote: > I also realized this while working on this bug. So I dropped my first > patches and now use isAutoRepeated in the committed patch, by this > a keystroke produced by a user will never get lost. > All typed keystrokes are in the event queue even when the user > types with 1 key/sec. Sounds good. Please make sure this gets extensively tested on different platforms. Andre'
