Re: gui 'slow' with remote X ?

[Fred Kiefer]

hns@computer.org wrote:
>> 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.
> 
> Doesn't it use a simple XCopyArea() which is done completely on the
> Server?
> 
At least the xlib backend should be doing this, but I am unsure whether
there are paths where we don't hit this case.

>> 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.
> 
> Well, I think you are requiring he Xrender extensions for older X11
> servers.
> 
> If they have this extension, I would suggest to switch to the cairo
> backend. That is already Xrender based.
> 

I fully agree with Nikolaus here. Handling Xrender ourselves is unneeded
hassle,
let cairo do this for us.

Fred