On Mon, 2005-05-30 at 12:50, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > | On Mon, 2005-05-30 at 10:56, Lars Gullik Bjønnes wrote: > >> Martin Vermeer <[EMAIL PROTECTED]> writes: > >> > >> | On Sat, May 28, 2005 at 12:12:07AM +0200, Lars Gullik Bjønnes wrote: > >> >> | Actually I have now had time to think about this for two weeks, and my > >> >> | considered opinion is a bit different... > >> >> > >> >> What you write belowe seems very sane. But I think that my keyevent > >> >> queue is still needed? (but to fix a different problem) > >> > > >> | Which problem? > >> > > >> | I have the feeling that pruning repeat key events is not wrong in > >> | principle, but at best not needed. Without it, you know precisely > >> | (under my scheme) that keeping the PgDown key down for 0.5 secs will get > >> | you 10 screens lower, only a few of which will actually be displayed due > >> | to the X coalescing behaviour. > >> > >> Do you want that? To not know exactly that when you release the button > >> scrolling stops. I just hate it when the cursor or screen continue to > >> move after key release. > > > | It doesn't really. It just finishes the ongoing screen rendering (if > | any) and then does the final one. And the scroll bar is all the time > | almost up-to-date. It's feels very predictable. > > > >> (More precisely: if a screen refresh > >> | takes 0.4 s and key repeat is 20/s, every 8th screen will be rendered, > >> | plus-minus, including the final one when you lift your finger.) Under > >> | your scheme, scrolling will be equally regular (right?) but slower. > >> > >> No. Not slower, but "synchronous". > > > | It cannot be equally fast if it renders every screen. It's the > | coalescing that produces the speed-up. > > Key events are not coalesced (or have you dont something I have not > noticed?) without my patch. Sure my patch also > does not do it, but it could... Note that pruning is only done if > the screen update cannot keep up with the incomming keyevents. So as > such we could make the keyevent timer auto adjusting.)
Screen _drawing_ events are coalesced. Every time you press the PgDn key, LyX will make X schedule/queue (?) a text drawing event of the whole screen for execution. Now if these accumulate in the queue, apparently X removes all but the last one. So, not all screens are drawn upon key repeat, saving time: actually no keystroke backlog will build up. Handling the keystroke itself takes very little time. > How fast is the Qt event loop? No idea. Variable, I suppose, depending on events being executed. > is it possible to register a function that is run on every iteration? ? - Martin
signature.asc
Description: This is a digitally signed message part
