On 12 apr. 2013, at 08:41, Eli Zaretskii <[email protected]> wrote: >> From: Carsten Dominik <[email protected]> >> Date: Fri, 12 Apr 2013 00:49:32 +0200 >> Cc: "[email protected] List" <[email protected]> >> >>> Overlays should be OK as long as they aren't too many, and as long as >>> you don't move them around too much, particularly in post-command-hook >>> or some such. >> >> This explanation sounds to me as if the display engine is building >> some kind of tree of overlays to find properties changes quickly. Too bad I >> don't have time to understand this stuff in more detail, it sounds >> interesting. > > Just search xdisp.c for "overlay", you will see the story quite > clearly, I think.
My Sunday pleasure reading project. > > There are actually 2 aspects that make display engine's job harder > with overlays. One is indeed that finding overlays that "cover" a > given buffer position is not a very efficient operation. The display > engine tries to overcome this to some extent by "centering" the > overlay data base around the place in the buffer it is rendering. > This is done for every screen line that is being examined by the > display code. > > The other problem is that there's no easy way of finding out which > parts of the buffer are being affected by changes in overlays. The > consequence of this is that redisplay cannot easily determine whether > a given portion of what's on the glass needs to be redrawn when > overlays change. The analysis of which part(s) of a window need to be > redrawn is at the heart of redisplay optimizations, whereby Emacs > tries very hard to reuse the portions of display that are already up > to date. Changes in overlays defeat that. Therefore, changing _any_ > overlays in a buffer disables most, if not all, redisplay > optimizations, meaning that the entire portion of the buffer that is > displayed will be completely redrawn each time overlays _anywhere_ in > the buffer are changed. Wow. OK. I need to think to that, and I will try to take a fresh look at overlay use in Org. So the reason that the combination with hi-line is slow is because hl-line is using post-command-hook to move its overlay, and redisplay of a full window with org-mode is slow because so much stuff is hidden and Emacs makes a full re-evaluation of what needs to be displayed? This makes sense. Thanks for taking the time to get me this far. - Carsten
