Re: Slow image display over network

[David Kastrup <dak@gnu.org>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I don't think that this is relevant for remote operation.  Emacs goes
>> through a complex call chain for every single pixel of an X image in
>> order to create it.  Quite nonsensical.
>
> So are you suggesting that this can be fixed?

You are in a twisty little maze of per-pixel procedure calls, all alike.
Intermingled is the display alpha channel correction.  Calculated fresh
for every pixel.

Of course it would make sense to batch all of this and do calls only for
whole pictures or rectangles.  That needs restructuring the code.

If that is done well, it would make sense to route the color management
on a Gtk target completely through Gdk: it does a good and
well-optimized job with it.  But you won't get much of an improvement if
you call Gdk again for every pixel.

>> Once it is through, it goes to the X server as one image if I am not
>> mistaken, and gets moved into a pixmap (the Emacs image cache).  So
>> the worst that can happen is that it is in a format not best for
>> remote transfer.
>
> First it's transferred pixel-by-pixel, and then it's transferred as an
> image?

No.  First it is _created_ entirely on the client side using a call
chain ending in Xlib calls, pixel-by-pixel for the whole call chain.
Then the X Image (which is a client-side data structure) is transferred
into a Pixmap (which is a server-side data structure) as one piece.

So while Xlib is called over and over, the actual traffic to the X
server should be tolerably optimized.

All of this speaking just from memory of when I last looked at the Emacs
21 display engine.

-- 
David Kastrup