Re: Rethinking the design of xwidgets

[Akira Kyle]

On Wed, Oct 14, 2020 at 12:32 PM, Eli Zaretskii <eliz@gnu.org> 
wrote:

> > I see some redisplay tests in 
> > tests/manual/redisplay-testsuite.el 
> > and scroll-tests.el which seems like it would be a starting 
> > point 
> > for such a study?
>
> No, not necessarily.  Those just test some tricky situations 
> where
> there were bugs at some point.
>
> To find the set of tests to measure the effect of the 
> optimizations,
> I'd suggest the following procedure:
>
>   . For each of the optimizations, find a situation where each 
>   that
>     optimizations gets executed.  ("M-x trace-redisplay" can 
>     help
>     here.)  Then measure the performance with and without the
>     optimization (most of them can be inhibited by setting the
>     relevant inhibit-try-* variables; for the couple that 
>     cannot, we
>     can add more such variables).
>     Note that some optimizations are in xdisp.c and some in 
>     dispnew.c.
>
>   . Each test case found above should be run with and without
>     variable-size fonts, with and without text properties 
>     (font-lock),
>     and with and without lots of overlays.
>
>   . Additional test cases can be constructed by benchmarking 
>   scrolling
>     through a large buffer, again with and without the relevant
>     optimizations.
>
> I guess there's more, but the above can be a good starting 
> point, and
> will produce enough data to analyze the current situation.

Thanks for the outline of how to start on this project. I'll add 
it to my list of Emacs projects I'd like to work on whenever I 
have time to do so :)

> > I am a user who frequently wishes redisplay was better which 
> > has
> > partly motivated my interest in this. Between displaying long 
> > org
> > mode documents with inline images and long lines of generated 
> > latex,
> > I'll often see noticeable delay in basic buffer operations such 
> > as
> > scrolling. This is also exacerbated by the fact that I'm doing 
> > all
> > of this on a Pinebook Pro which is an arm aarch64 system 
> > comparable
> > to the raspberry pi. In fact the only way Emacs has been 
> > generally
> > usable for me on this laptop is with the native-comp branch.
>
> It is possible that a significant portion of the percepted 
> slowness is
> due to Lisp that is run either via redisplay hooks or from
> post-command-hook and suchlikes.  To see who is the culprit, 
> profile
> Emacs during such slow displays, and look at the percentage 
> taken by
> redisplay_internal and vertical-motion, as opposed to other 
> functions.

Sorry I should've been more precise. I'm sure much of the 
perceived slowness is due to lisp given how much native-comp 
improves the situation. My wishes for redisplay to be better are 
less performance related (expect for long lines which are are a 
real killer) and more functionality wise, hence the original 
proposal about xwidgets. I also think Emacs could handle scrolling 
variable height lines much better as when there are inline images 
in a buffer and generally handle being more aware about pixels 
rather than the character matrix positions that Emacs historically 
started out only caring about.