Re: Rethinking the design of xwidgets

[Akira Kyle <ak@akirakyle.com>]

On Wed, Oct 14, 2020 at 08:33 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

>> Can actions be triggered on a click and drag as one would do to 
>> pan within a plot?
>
> I didn't have time to try that, but just looking at the code, I 
> don't
> see anything that makes the clocks on images special, so I'd 
> expect
> the same modifiers and drag-detection code to work.  And if it
> doesn't, I seed no reason why we couldn't teach it to do so.

Good to know.

>> As far as I know there are really only two FLOSS PDF libraries 
>> out 
>> there: poppler and muPDF. Between them poppler supports more 
>> PDF 
>> features and seems to be more widely used. I agree this isn't 
>> really as compelling of a use case for xwidgets, but I seems 
>> like 
>> it would be easier to achieve better PDF rendering via 
>> xwidgets.
>
> I can see how that is tempting: the image handling is taken care 
> of.
> What I'm saying is that this advantage should be carefully 
> weighed
> against the disadvantages and difficulties in integrating such
> self-managing objects into the Emacs display code.

OK. I'm still learning about the redisplay optimizations so 
hopefully I'll have a better idea of what those disadvantages are 
as I play with the existing way xwidgets works with redisplay.

>> > E.g., the kludge in dispnew.c around line 4365.  It disables 
>> > one
>> > of the most important redisplay optimizations in Emacs, once 
>> > you
>> > build with xwidgets enabled.
>> 
>> Ah, I had briefly looked at that but I wasn't sure how 
>> important 
>> it was. I may be able to make some progress on that but it's 
>> hard 
>> to understand the context for that function. It seems like that 
>> function is responsible for an optimization that avoids 
>> redrawing 
>> glyphs if the window is being scrolled by copying them
>
> Not only if the window is scrolled, but also if the previous 
> display
> can be converted into the current display by scrolling some of 
> the
> stuff that is already on the glass.  the algorithm is a basic
> comparison of the current and desired display, similar to what 
> the
> Diff utility does.
>
>> however I couldn't find where or how the glyphs are actually 
>> copied?
>
> See the calls to rif->scroll_run_hook.

Thanks, this helps!

>> I'm just starting to dig my teeth into some of that. However 
>> I'm 
>> wondering if anyone has more recently tried to quantify the 
>> improvements the various redisplay optimizations make to both 
>> actual and perceived render time of Emacs. For example the 
>> comment 
>> on the scrolling_window function in dispnew.c that you pointed 
>> me 
>> too references that it is implementing an algorithm from 1978, 
>> perhaps it would be worth exploring if there are any 
>> algorithmic 
>> advances?
>
> I don't think that algorithm is less optimal nowadays than it 
> was back
> then; the really interesting question is how much it saves us 
> when
> compared to simply redisplaying all those lines.

Yes that is the better question to ask first.

>> It strikes me that perhaps some optimizations may no longer be 
>> as
>> necessary on modern hardware or on GUI displays as they were 
>> when
>> running emacs in a VT on 20 year hardware.
>
> Those are very good questions.  I'm not aware of any such
> investigations since the current redisplay optimizations were
> implemented around 20 years ago: at that time, Gerd Möllmann, 
> who
> developed the current display engine, did add optimizations one 
> by one
> until he got reasonable redisplay performance.
>
> Measuring the speedups from each of the several optimizations is 
> an
> important job, but it's a large job.  For starters, one needs to 
> come
> up with a large enough and representative enough sample of 
> redisplay
> use cases, and that is not easy.  So I'd encourage you (or 
> anyone
> else, actually) to do this important job, but be aware that it 
> could
> take non-trivial time and effort.

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?

>> Conversely there may be further optimization that could be done 
>> by
>> taking advantage of more recent hardware advances such as 
>> offloading
>> to a GPU or utilizing vectorized instructions.
>
> We try not to use machine-dependent code in Emacs, because 
> that's a
> maintenance burden, what with today's fast pace of chip 
> development
> and obsolescence.  Vectorization is generally left to optimizing
> compilers, and relying on special hardware, such as GPU, is not
> something we should depend on directly.  We should instead hope 
> that
> the GUI toolkits and display systems we use will do that for us.

That's more what I meant.

>> If there's one think I've taken away from my CS education, its 
>> that
>> indeed "premature optimization is the root of all evil".
>
> The optimizations we have today were definitely NOT premature 
> when
> they were introduced.  How much they are still needed today is 
> indeed
> an interesting and important question that still awaits the 
> motivated
> investigators.  I have only indirect evidence that some of the
> optimizations still do a useful job: compare the redisplay 
> performance
> when linum-mode is turned on with the performance when the 
> native
> display-line-numbers-mode is used instead.  Also, we frequently 
> hear
> complaints about redisplay performance, even if you take away 
> the
> problems with long lines.

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.