Hi Josef, On Thu, May 24, 2007 at 07:13:26PM +0200, Josef Weidendorfer wrote: > > Basically, local retypesetting is done after every change. > > When typesetting is done, we render, text close to the cursor first. > > The rendering process is interrupted on a new keyboard event, > > even though a minimal number of boxes are always redisplayed. > > I tried to come up with an extreme case to be able to reproduce how > this works. I made up one single paragraph with around 100 lines and > _lots_ of font changes (around 6 per line). > Finally I got a latency of around 1/3 of a second from typing one char > to display. This made some observations possible.
Yes, this sounds reasonable; it corresponds to about 30ms for a more typical 10 lines paragraph with many font changes. > * Most of the time, you append characters at the end of the paragraph. > I imagined that this should be faster than typing in the middle, but > this assumption obviously is wrong; the whole paragraph is relayouted > even in this case. Of course, this is totally correct. Yes, layout is heavily paragraph-based, so this is a natural minimal entity. > We could cheat here: do only a relayout from the typing position to > the end of the paragraph after every key, and a complete relayout > only when idle. Yes, I started to rewrite the typesetter in a more lazy way to do this. However, this is really a gambling project: we'll know whether it works after several months of work. Maybe it will just fail. One of the things which I fear most is memory consumption: the lasier, the more computations are remembered, the more space is consumed, and ..., the more cache misses... > However, I did not check the code if this is easily possible at all. > > * When typing faster than display latency, it can last a few seconds > before you see anything of your typing. This means that: > (1) relayouting seems to be done for key press (otherwise it should > last a maximum of 0.3 seconds to display after fast typing) At the moment, this correct. The point is that the correct handling of the next keyboard event may require a typeset document (e.g. cursor movement). Things might be made lasier though, or optimized when you type alpha-numerical characters. > (2) any redrawing gets completely suppressed when texmacs is busy No, TeXmacs will always attempt to redraw a few boxes close to your cursor. However, when the typesetter is really slow, delays will be accumulated. > And in more detail... > > CPU_CLK_UNHALT...|INST_RETIRED:8... > samples % samples % image name symbol name > 5353 16.2473 6921 17.9561 texmacs.bin hashmap_rep<string, > string>::bracket_ro(string) > 3192 9.6883 3599 9.3374 texmacs.bin > string::operator()(int, int) > 2371 7.1964 3002 7.7885 texmacs.bin get_hyphens(string, > hashmap<string, string>) > 1717 5.2114 2521 6.5406 texmacs.bin hash(string) > 1007 3.0564 1521 3.9461 texmacs.bin operator new(unsigned > int) > 972 2.9502 1128 2.9265 texmacs.bin > line_breaker_rep::process(list<int>) > 812 2.4646 902 2.3402 texmacs.bin > string::operator==(char*) > 804 2.4403 1379 3.5777 texmacs.bin operator delete(void*) > 775 2.3523 1000 2.5944 libguile.so.17.0.1 deval > 696 2.1125 420 1.0897 texmacs.bin > tex_font_rep::get_extents(string, metric_struct ( > 671 2.0366 1194 3.0978 texmacs.bin operator > new[](unsigned int) > 608 1.8454 847 2.1975 texmacs.bin > string_rep::~string_rep() Thanks. > [Note that there is really nothing to optimize in the following > functions if the above suggested optimizations can be done!] Yep, I did similar profiling a few years ago and already did most of the obvious optimizations... Best wishes, Joris _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
