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, processEvents - success
José Matos wrote: On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run make install and run the (same) installed LyX, then I can't open documents, not even the help documents or a new document - because lyx2lyx fails me. Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 09:48:58 Helge Hafting wrote: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run make install and run the (same) installed LyX, then I can't open documents, not even the help documents or a new document - because lyx2lyx fails me. I understand the reason, but it is strange. If you run lyx from the console what is the error output? Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Thursday 24 May 2007 09:48:58 Helge Hafting wrote: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run make install and run the (same) installed LyX, then I can't open documents, not even the help documents or a new document - because lyx2lyx fails me. I understand the reason, but it is strange. If you run lyx from the console what is the error output? First a messagebox: /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of lyx, but the lyx2lyx script failed to convert it. So - this will probably fix itself if I delete the old .lyx directory. But ordinary users won't understand this sort of thing. The old defaults.lyx is from an earlier 1.5svn. Now, this shouldn't happen if there is a policy of supporting even files written by beta versions. The console error message: Warning: 271: Format not supported. Warning: Quiting. Error: Conversion script failed /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of LyX, but the lyx2lyx script failed to convert it. On the side: Perhaps the failed version (217) should be displayed in the dialog box too? Surely that would help if ever some confused user reports a problem? Looking at the defaults.lyx file, it is actually \lyxformat 263 The document type is my own layout. Of course that one might be buggy - but the same happens with the userguide. I notice that I get exactly the same messages for the userguide, so I wonder: Do lyx2lyx read defaults.lyx when other documents are processed too? If so - why? Also, why would lyx2lyx bother processing the userguide distributed with LyX, surely that one should be the right version to begin with? Or maybe not in a beta version. :-) Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: $ PYTHONPATH=../../lyx/lyx-devel/lib/lyx2lyx/ src/lyx Where path points to the source dir. The other option is to test the attached patch. Does it works for you? I cant do a useful test of the patch right now. I did a make install of the current source, and the problem just went away. I'll try if this starts happening again though. Even my own .layout works . Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 10:19:11 Helge Hafting wrote: First a messagebox: /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of lyx, but the lyx2lyx script failed to convert it. So - this will probably fix itself if I delete the old .lyx directory. But ordinary users won't understand this sort of thing. The old defaults.lyx is from an earlier 1.5svn. Now, this shouldn't happen if there is a policy of supporting even files written by beta versions. The policy is there and is working. :-) The console error message: Warning: 271: Format not supported. Warning: Quiting. Error: Conversion script failed /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of LyX, but the lyx2lyx script failed to convert it. This shows that lyx2lyx was not updated. :-) This can happen if you update the src directory but not from the root directory. This has happened before. :-) On the side: Perhaps the failed version (217) should be displayed in the dialog box too? Surely that would help if ever some confused user reports a problem? We can improve the error report but this is a 1.6 issue. Looking at the defaults.lyx file, it is actually \lyxformat 263 The document type is my own layout. Of course that one might be buggy - but the same happens with the userguide. I notice that I get exactly the same messages for the userguide, so I wonder: Do lyx2lyx read defaults.lyx when other documents are processed too? If so - why? As I said above the problem was that the lyx2lyx version was not up to date. Also, why would lyx2lyx bother processing the userguide distributed with LyX, surely that one should be the right version to begin with? Or maybe not in a beta version. :-) We update all the documentation to the latest stable format just before releasing the stable version as there is no guarantee before that format will stay fixed. Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 10:37:37 Helge Hafting wrote: I cant do a useful test of the patch right now. I did a make install of the current source, and the problem just went away. I'll try if this starts happening again though. Those are the reports I like to read. :-) Even my own .layout works . Why shouldn't it? ;-) Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: This shows that lyx2lyx was not updated. :-) This can happen if you update the src directory but not from the root directory. This has happened before. :-) I guess that is what happened. I have to be more careful with the svn commands then. Thanks for the tip. Helge Hafting
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, processEvents - success
José Matos wrote: On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run "make install" and run the (same) installed LyX, then I can't open documents, not even the help documents or a "new" document - because lyx2lyx fails me. Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 09:48:58 Helge Hafting wrote: > My problem is the exact opposite. > If I run LyX from the source dir, then I can open documents. > If I then run "make install" and run the (same) installed LyX, > then I can't open documents, not even the help documents > or a "new" document - because lyx2lyx fails me. I understand the reason, but it is strange. If you run lyx from the console what is the error output? > Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Thursday 24 May 2007 09:48:58 Helge Hafting wrote: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run "make install" and run the (same) installed LyX, then I can't open documents, not even the help documents or a "new" document - because lyx2lyx fails me. I understand the reason, but it is strange. If you run lyx from the console what is the error output? First a messagebox: /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of lyx, but the lyx2lyx script failed to convert it. So - this will probably fix itself if I delete the old .lyx directory. But ordinary users won't understand this sort of thing. The old "defaults.lyx" is from an earlier 1.5svn. Now, this shouldn't happen if there is a policy of supporting even files written by beta versions. The console error message: Warning: 271: Format not supported. Warning: Quiting. Error: Conversion script failed /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of LyX, but the lyx2lyx script failed to convert it. On the side: Perhaps the failed version (217) should be displayed in the dialog box too? Surely that would help if ever some confused user reports a problem? Looking at the defaults.lyx file, it is actually \lyxformat 263 The document type is my own layout. Of course that one might be buggy - but the same happens with the userguide. I notice that I get exactly the same messages for the userguide, so I wonder: Do lyx2lyx read defaults.lyx when other documents are processed too? If so - why? Also, why would lyx2lyx bother processing the userguide distributed with LyX, surely that one should be the right version to begin with? Or maybe not in a beta version. :-) Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: $ PYTHONPATH=../../lyx/lyx-devel/lib/lyx2lyx/ src/lyx& Where path points to the source dir. The other option is to test the attached patch. Does it works for you? I cant do a useful test of the patch right now. I did a "make install" of the current source, and the problem just went away. I'll try if this starts happening again though. Even my own .layout works . Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 10:19:11 Helge Hafting wrote: > First a messagebox: > /home/helgehaf/.lyx/templates/defaults.lyx > is from a different version of lyx, > but the lyx2lyx script failed to convert it. > > So - this will probably fix itself if I delete the old .lyx directory. > But ordinary users won't understand this sort of thing. The old > "defaults.lyx" is from an earlier 1.5svn. Now, this shouldn't happen > if there is a policy of supporting even files written by beta versions. The policy is there and is working. :-) > The console error message: > Warning: 271: Format not supported. > Warning: Quiting. > Error: Conversion script failed > > /home/helgehaf/.lyx/templates/defaults.lyx is from a different version > of LyX, but the lyx2lyx script failed to convert it. This shows that lyx2lyx was not updated. :-) This can happen if you update the src directory but not from the root directory. This has happened before. :-) > On the side: Perhaps the failed version (217) should be displayed in the > dialog box too? Surely that would help if ever some confused user > reports a problem? We can improve the error report but this is a 1.6 issue. > Looking at the defaults.lyx file, it is actually \lyxformat 263 > The document type is my own layout. Of course that one > might be buggy - but the same happens with the userguide. > > I notice that I get exactly the same messages for the userguide, > so I wonder: Do lyx2lyx read defaults.lyx when other documents > are processed too? If so - why? As I said above the problem was that the lyx2lyx version was not up to date. > Also, why would lyx2lyx bother processing the userguide > distributed with LyX, surely that one should be the right version > to begin with? Or maybe not in a beta version. :-) We update all the documentation to the latest stable format just before releasing the stable version as there is no guarantee before that format will stay fixed. > Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 10:37:37 Helge Hafting wrote: > I cant do a useful test of the patch right now. I did a "make install" > of the current source, and the problem just went away. > I'll try if this starts happening again though. Those are the reports I like to read. :-) > Even my own .layout works . Why shouldn't it? ;-) > Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: This shows that lyx2lyx was not updated. :-) This can happen if you update the src directory but not from the root directory. This has happened before. :-) I guess that is what happened. I have to be more careful with the svn commands then. Thanks for the tip. Helge Hafting
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, testing event2
Peter Kümmel wrote: Helge Hafting wrote: 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. I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? I tried this patch too, and the problems persist. How I test: 1. Open the user guide. 2. Scroll by holding down the mouse button inside the scrollbar, so that it jump scrolls. This is the worst case. Scrollbar arrows or keyboard scrolling isn't as bad. I always get the same result. A small window does not push the cpu to 100%, and then scrolling stops instantaneosly. A full-screen window (1280x1024) push the cpu to 100% usage, and then scrolling overshoots with many pages. I have also tested a two-pc setup, one pc running LyX and another running the xserver (showing the LyX window). They were connected with an ADSL link. There were some interesting results: Driving the cpu to 100% on the xserver machine lead to the same problems of overshooting. A large LyX window scrolling causes this, or a small LyX window scrolling while the xserver machine compiles something. This case was neither worse nor better than running LyX locally. A small LyX window scrolling on an otherwise idle xserver has no problem. It is nice to see that LyX still performs nicely with a networked display. The network overhead and latency is apparently not part of this problem. Driving the load to 100% by compiling on the machine running LyX actually _helped_ somewhat. There was still overshooting when using a large window, but not as much. Looks like giving the LyX binary less time to run gave it less opportunity to queue up extra scrolling for the future. So the problems happen when LyX is working faster than its display. :-/ A guess: If you try to stop scrolling action as soon as there is a mouseup event but it doesn't work - chances are you aren't getting the event in time because the computer is so busy performing the scrolling. Who nows - perhaps something as strange as a very short sleep after each scrolljump could help with this? Unless someone knows a better way? Sleeping to solve performance problems seems weird, but it might provide enough time for the mouseup event to get delivered? Helge Hafting
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, processEvents - success
Peter Kümmel wrote:
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?
I replaced the two flush calls with processEvents. (Altered patch
attached if anyone else want to test it for improvement or regression)
This helped a lot in a short test!
Not entirely perfect, but much better when scrolling the
maximized userguide using the scrollbar. Instead of overshooting
by many pages, it often stopped when I wanted to, or sometimes
overshot by half a page.
Seems you're on the right track with this, and if we can get some
drawing optimizations as well then LyX 1.5 will be really good.
Unfortunately, I didn't get to test it with a loaded machine.
I did a make install and then a make clean; make in
order to test overshooting during a compile. But starting
exactly the same lyx binary after installation didn't work -
I got stupid messages about the userguide being in an
different version, and lyx2lyx failed! Creating a new
lyx document failed the same way, as lyx2lyx failed to convert the
default template too.
I guess a different version of lyx2lyx ran when I ran lyx from the
build directory instead of installing it. :-/
Helge Hafting
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::processEvents();
}
+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
Re: Scrolling lag in 1.5svn again, more processEvents testing
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? I finally got LyX running again, and tested scrolling with a background compile going on. As expected, LyX scrolled slower. It was possible to have it overshoot by several pages, but it was much better than without the patch. I now have to scroll for some time before it will overshoot massively. The problem is smaller, and the patch helps even more when the machine isn't doing other work. Scrolling through series of large paragraphs of _text_ seems to be the worst. If I release the mouse button as the platypus image rolls by, then LyX stops scrolling instantly. Even if there is a background compile going on. Releasing when the big LyX window is full of text can still lead to overshooting. Other places with less text content (big tables, lots of headings with much white spave between them) are also good places to stop scrolling. Helge Hafting
Re: Scrolling lag in 1.5svn again, fast typing problem?
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? I just saw a nasty problem, using the processEvents version of the patch: 1. Insert a listing. 2. Inside the listing, insert a caption 3. Type fast inside that caption. Notice how LyX eats some of the keystrokes. Ouch! :-( :-( :-( 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, processEvents - success
On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: $ PYTHONPATH=../../lyx/lyx-devel/lib/lyx2lyx/ src/lyx Where path points to the source dir. The other option is to test the attached patch. Does it works for you? Helge Hafting -- José Abílio Index: lib/lyx2lyx/LyX.py === --- lib/lyx2lyx/LyX.py (revision 18390) +++ lib/lyx2lyx/LyX.py (working copy) @@ -26,8 +26,11 @@ import re import time -import lyx2lyx_version -version_lyx2lyx = lyx2lyx_version.version +try: +import lyx2lyx_version +version_lyx2lyx = lyx2lyx_version.version +except: # we are running from build directory so assume the last version +version_lyx2lyx = '1.5.0svn' default_debug_level = 2
Re: Scrolling lag in 1.5svn again, -dbg 8 output
Thanks for the intensive testing, Helge!
Helge Hafting wrote:
void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 1175 curr
par: 905 default height 32
scrolling: one event posted
void lyx::BufferView::scrollDocView(int)[ value = 259297]
void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 1175 curr
par: 905 default height 32
scrolling: one event posted
This output shows the problem: all scroll events are posted
even when the xsever hasn't finishes the last one.
One way to fix this is to replace the flush() call with
QApplication::syncX(), then on each event LyX is waiting
for the xserver, but this gives bad scroll performance.
Attached a patch which also checks if the x11-queue is empty
(2: page down doesn't work with 1 - the patch becomes more
and more a hack).
When you run with -dbg 8 you will see the how full the
x11 queue is. Here it is never more than 1 event in the queue,
seems this is the reason why I coudn't reproduce your scrolling
bug. I hope you see numbers bigger than 1.
What for a linux distro is on your system? Maybe it is the xserver
configuration.
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (Revision 18433)
+++ src/frontends/qt4/GuiWorkArea.cpp (Arbeitskopie)
@@ -54,6 +54,10 @@
int const CursorWidth = 1;
#endif
+#ifdef Q_WS_X11
+#include QX11Info
+extern C int XEventsQueued(Display *display, int mode);
+#endif
using std::endl;
using std::string;
@@ -63,6 +67,17 @@
namespace lyx {
+#ifdef Q_WS_X11
+bool xEventsProcessed() {
+ QApplication::flush();
+ int events = XEventsQueued(QX11Info::display(), 0 /* QueuedAlready */)
== 0;
+ LYXERR(Debug::GUI) X11 queue events\n;
+ return events 2;
+}
+#else
+bool xEventsProcessed() { return true; }
+#endif
+
using support::FileName;
/// return the LyX key state from Qt's
@@ -190,8 +205,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 +229,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 +296,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 xEventsProcessed()) {
+ 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 +472,14 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
Re: Scrolling lag in 1.5svn again, -dbg 8 output
Peter Kümmel wrote: When you run with -dbg 8 you will see the how full the x11 queue is. Here it is never more than 1 event in the queue, Hope you could understand these sentences ;) Peter
Re: Scrolling lag in 1.5svn again, testing event2
Peter Kümmel wrote: Helge Hafting wrote: 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. I'm running out of ideas... Is this patch better (the flush call is new)? Or with processEvents instead of flush? I tried this patch too, and the problems persist. How I test: 1. Open the user guide. 2. Scroll by holding down the mouse button inside the scrollbar, so that it jump scrolls. This is the worst case. Scrollbar arrows or keyboard scrolling isn't as bad. I always get the same result. A small window does not push the cpu to 100%, and then scrolling stops instantaneosly. A full-screen window (1280x1024) push the cpu to 100% usage, and then scrolling overshoots with many pages. I have also tested a two-pc setup, one pc running LyX and another running the xserver (showing the LyX window). They were connected with an ADSL link. There were some interesting results: Driving the cpu to 100% on the xserver machine lead to the same problems of overshooting. A large LyX window scrolling causes this, or a small LyX window scrolling while the xserver machine compiles something. This case was neither worse nor better than running LyX locally. A small LyX window scrolling on an otherwise idle xserver has no problem. It is nice to see that LyX still performs nicely with a networked display. The network overhead and latency is apparently not part of this problem. Driving the load to 100% by compiling on the machine running LyX actually _helped_ somewhat. There was still overshooting when using a large window, but not as much. Looks like giving the LyX binary less time to run gave it less opportunity to queue up extra scrolling for the future. So the problems happen when LyX is working faster than its display. :-/ A guess: If you try to stop scrolling action as soon as there is a mouseup event but it doesn't work - chances are you aren't getting the event in time because the computer is so busy performing the scrolling. Who nows - perhaps something as strange as a very short sleep after each scrolljump could help with this? Unless someone knows a better way? Sleeping to solve performance problems seems weird, but it might provide enough time for the mouseup event to get delivered? Helge Hafting
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, processEvents - success
Peter Kümmel wrote:
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?
I replaced the two flush calls with processEvents. (Altered patch
attached if anyone else want to test it for improvement or regression)
This helped a lot in a short test!
Not entirely perfect, but much better when scrolling the
maximized userguide using the scrollbar. Instead of overshooting
by many pages, it often stopped when I wanted to, or sometimes
overshot by half a page.
Seems you're on the right track with this, and if we can get some
drawing optimizations as well then LyX 1.5 will be really good.
Unfortunately, I didn't get to test it with a loaded machine.
I did a "make install" and then a "make clean; make" in
order to test overshooting during a compile. But starting
exactly the same lyx binary after installation didn't work -
I got stupid messages about the userguide being in an
different version, and lyx2lyx failed! Creating a new
lyx document failed the same way, as lyx2lyx failed to convert the
default template too.
I guess a different version of lyx2lyx ran when I ran lyx from the
build directory instead of installing it. :-/
Helge Hafting
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::processEvents();
}
+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
Re: Scrolling lag in 1.5svn again, more processEvents testing
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? I finally got LyX running again, and tested scrolling with a background compile going on. As expected, LyX scrolled slower. It was possible to have it overshoot by several pages, but it was much better than without the patch. I now have to scroll for some time before it will overshoot massively. The problem is smaller, and the patch helps even more when the machine isn't doing other work. Scrolling through series of large paragraphs of _text_ seems to be the worst. If I release the mouse button as the platypus image rolls by, then LyX stops scrolling instantly. Even if there is a background compile going on. Releasing when the big LyX window is full of text can still lead to overshooting. Other places with less text content (big tables, lots of headings with much white spave between them) are also good places to stop scrolling. Helge Hafting
Re: Scrolling lag in 1.5svn again, fast typing problem?
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? I just saw a nasty problem, using the processEvents version of the patch: 1. Insert a listing. 2. Inside the listing, insert a caption 3. Type fast inside that caption. Notice how LyX eats some of the keystrokes. Ouch! :-( :-( :-( 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, processEvents - success
On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: > I guess a different version of lyx2lyx ran when I ran lyx from the > build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: $ PYTHONPATH=../../lyx/lyx-devel/lib/lyx2lyx/ src/lyx& Where path points to the source dir. The other option is to test the attached patch. Does it works for you? > Helge Hafting -- José Abílio Index: lib/lyx2lyx/LyX.py === --- lib/lyx2lyx/LyX.py (revision 18390) +++ lib/lyx2lyx/LyX.py (working copy) @@ -26,8 +26,11 @@ import re import time -import lyx2lyx_version -version_lyx2lyx = lyx2lyx_version.version +try: +import lyx2lyx_version +version_lyx2lyx = lyx2lyx_version.version +except: # we are running from build directory so assume the last version +version_lyx2lyx = '1.5.0svn' default_debug_level = 2
Re: Scrolling lag in 1.5svn again, -dbg 8 output
Thanks for the intensive testing, Helge!
Helge Hafting wrote:
> void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 1175 curr
> par: 905 default height 32
> scrolling: one event posted
> void lyx::BufferView::scrollDocView(int)[ value = 259297]
> void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 1175 curr
> par: 905 default height 32
> scrolling: one event posted
This output shows the problem: all scroll events are posted
even when the xsever hasn't finishes the last one.
One way to fix this is to replace the flush() call with
QApplication::syncX(), then on each event LyX is waiting
for the xserver, but this gives bad scroll performance.
Attached a patch which also checks if the x11-queue is empty
(<2: page down doesn't work with <1 -> the patch becomes more
and more a hack).
When you run with -dbg 8 you will see the how full the
x11 queue is. Here it is never more than 1 event in the queue,
seems this is the reason why I coudn't reproduce your scrolling
bug. I hope you see numbers bigger than 1.
What for a linux distro is on your system? Maybe it is the xserver
configuration.
Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp (Revision 18433)
+++ src/frontends/qt4/GuiWorkArea.cpp (Arbeitskopie)
@@ -54,6 +54,10 @@
int const CursorWidth = 1;
#endif
+#ifdef Q_WS_X11
+#include
+extern "C" int XEventsQueued(Display *display, int mode);
+#endif
using std::endl;
using std::string;
@@ -63,6 +67,17 @@
namespace lyx {
+#ifdef Q_WS_X11
+bool xEventsProcessed() {
+ QApplication::flush();
+ int events = XEventsQueued(QX11Info::display(), 0 /* QueuedAlready */)
== 0;
+ LYXERR(Debug::GUI) << "X11 queue " << events << " \n";
+ return events < 2;
+}
+#else
+bool xEventsProcessed() { return true; }
+#endif
+
using support::FileName;
/// return the LyX key state from Qt's
@@ -190,8 +205,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 +229,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 +296,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 && xEventsProcessed()) {
+ 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 +472,14 @@
int const lines = qApp->wheelScrollLines() * e->delta() / 120;
Re: Scrolling lag in 1.5svn again, -dbg 8 output
Peter Kümmel wrote: > When you run with -dbg 8 you will see the how full the > x11 queue is. Here it is never more than 1 event in the queue, Hope you could understand these sentences ;) 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.
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
