On Wed, 2005-05-11 at 16:36, Bennett Helm wrote: > On May 11, 2005, at 6:55 AM, Jean-Marc Lasgouttes wrote: > > > It would be interesting to know how things have evolved since Martin's > > latest patch. > > Here you go -- profile attached, done the same way as my previous > report: tree view, with system libraries charged to callers; 30-second > sample, with me typing constantly during the sampling. > > The last time I tested lyx-140 -- just to see whether it felt like > there was an improvement -- was a couple days ago, and not much had > changed from when I first complained about slowness. However, my > subjective experience of the latest CVS is that things have gotten > markedly worse in the last 48 hours. When testing with an ordinary > blank document, things are fine. But with a large-ish document (about > 10000 words and with many footnotes, citations, and cross references, > but with no math or graphics), typing at a normal speed is simply > impossible: the order letters appear in the document is no longer the > order I type them. Thus, if I type "1234" quickly (but slowly enough to > be sure I'm typing them in that order!), I actually get "1342" or > "1432" in the document. Similarly, typing "The last time I tested lyx" > results in "The lsttim Iteted slyx e a". This did not happen before. > > Bennett
Oops, that's bad. Could this be due to calling sync_events twice during a cursor blink sequence? (both in showCursor and in hideCursor.) I did that to make LyX snappier ;-/ Alternatively, now the time between two calls to processEvents is never shorter than 0.4 sec. Could that be the problem? This time is set in the BufferView::Pimpl::Pimpl constructor. (Actually this isn't quite true: there are some calls to showCursor in the code where the blink counter is forcibly reset.) A third suspect: in BufferView_pimpl's update, we see that processEvents is masked from line 627 onward, i.e., during the first (metrics) drawing step, and the second. This didn't use to be so. I think this is right: allow_sync_ must be coordinated with startUpdating/doneUpdating. But it may cause extra delay. But... if it works right for small docs, perhaps we should look at the rendering efficiency scaling behaviour with size. Does anyone have an idea how the input order reversal could come about? Again, are there any guarantees that the X queue gives events back in time order? - Martin
signature.asc
Description: This is a digitally signed message part
