Re: Rethinking the design of xwidgets

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.

Right.  The relative performance of different kinds of code has probably
changed significantly, so it's possible that it's faster to just redraw
the whole window than to try and figure out which part to redraw (and
even try and find some scrolling opportunities in there).
Then again, it's also quite possible that those optimizations are still
very much worthwhile.

> In case where there is a discret gfx card (i.e. Nvidia/AMD) it is
> probably faster to send everything to GPU and ask it to render a 
> giant texture and then use it as XWindow pixmap, or something similar
> then to figure out on CPU all the stuff that should not be displayed.

I think it's much harder than it sounds: most of the work needs access
to data structures that aren't friendly to GPUs, so the work of
providing data to a GPU in an appropriate form would probably not be
much more less in most cases than the drawing itself.

(talking-about-things-one-does-not-understand-mode 1)

But indeed, maybe we could split the "drawing" from the glyph matrices
to the glass into a first step that draws into a "pixmap matrix" and
a second step that draws from it onto the glass.  This should make it
unnecessary to try and "scroll" (parts of) the display since it should
be "just as fast" to copy from the pixmap matrix as it is to copy from
the current glass's content.

(talking-about-things-one-does-not-understand-mode -1)

I think the performance of the redisplay is by and large poorly
understood.  While there are known cases where people experience "slow
redisplay" it's usually very unclear what that means concretely.
In many cases this can be completely unrelated to the actual redisplay
code (e.g. the time is spent running some expensive code off of
`post-command-hook` or font-lock or younameit).


        Stefan