John Levon wrote: > On Wed, May 11, 2005 at 06:12:53PM +0300, Martin Vermeer wrote: > >> What came back was the original problem why sync_events was introduced: >> when scrolling fast in big documents (PageDown) the screen update >> doesn't keep up. >> >> - // You are not expected to understand this. This forces Qt >> - // (the problem case) to deal with its event queue. This is >> - // necessary when holding down a key such as 'page down' or >> - // just typing: without this processing of the event queue, >> - // the cursor gets ahead of itself without a selection or >> - // workarea redraw having a chance to keep up. If you think >> - // you can remove this, try selecting text with the mouse >> - // in Qt, or holding Page Down on the User's Guide. >> >> Well, AFAICS that's only cosmetic. (Question: were there any >> non-cosmetic problems with this? I don't see any.) > > What a bizarre attitude! Cosmetics are how every single user interacts > with LyX, with the single exception of the LyX server. > > I am DEAD against breaking this. We absolutely have to process all > pending draw events before reshowing the cursor, IMHO.
Hmmmm. Rather than process all pending draw events fully, is it sufficient to process the last draw event and discard the earlier ones? Ie, we should be computing the metrics() on each page-down, but we should draw() only if there is no other draw event on the stack. (Basically it seems daft to generate a buffered pixmap if it isn't going to be used.) Is it possible to ascertain how many draw events are to be processed? -- Angus
