Re: gui 'slow' with remote X ?

[David Chisnall]

On 24 Nov 2008, at 11:20, Fred Kiefer wrote:

> I am willing to help with any improvements you come up with, as long  
> as
> it still works with an older X server (we need to stay compatible
> otherwise Riccardo will complain). Myself I never use X over a remote
> connection so I am not familiar with the issues this may be causing in
> GNUstep.
>
> Perhaps we can tackle the issues one by one. For example  
> forscrolling we
> are using NSCopyBits() and this should boil down to the most efficient
> way to copy data for a backend. If this is not the case we should  
> change
> the lowest level to be more efficient. And so on with other areas.

When I have a bit more time, I'd like to take a look at doing this.   
One thing that I think would make it a lot easier would be if -back  
had some awareness of the view hierarchy.  This would allow, for  
example:

- Views that don't change between updates to be stored in server-side  
pixmaps or (on newer X servers) Pictures.
- Redirecting views to Pictures for compositing with XRenderComposite  
on X servers that supported it, or to GL textures for more shiny  
transforms.
- Using XRenderComposite for drawing the translated image after a  
scroll.

The last of these is the most relevant part here.  As I recall, when  
we do a copy, we currently:

1) Copy the relevant parts into the (client-side) buffer.
2) Draw the new bits.
3) Copy the buffer to the client.

This is slow even on a single machine because it means doing the  
drawing on the CPU side of the bus and then throwing a big blob of  
data at the GPU.  A better model would be:

1) Have a Picture per view.
2) Use XRenderComposite to draw the old Picture onto itself with  
translated coordinates.
3) Draw the new parts in a new Picture.
4) Copy this to the server.
5) Render he new parts over the now-invalid parts of the old picture.
6) Composite this into the parent view.

This means you are transferring a lot less data and doing more on the  
GPU.  This is going to be particularly important on handheld devices,  
where you will be moving much of the work from the ARM core to the GPU  
core and freeing up the slow CPU to work on more important things.  A  
new X server can do all of these things in highly optimised CPU  
routines if no GPU is available, but something similar can be done  
with older parts of the X protocol.

David