Re: gui 'slow' with remote X ?

[Fred Kiefer]

David Chisnall wrote:
> On 23 Nov 2008, at 22:11, Riccardo Mottola wrote:
> 
>> Nice to see there is another user. FOr me, besides, GTK2 is slow too.
>> Cairo and Art are going to be slow. No work around. Try the faithful
>> xlib backend, which I use regularly. It will be faster, since instead
>> of shuffling bitmaps, it lets the server do the work, like font drawing.
>> If you disable anti-aliasing and use the fonts available on your local
>> machine (or have a font server) the speed increase will be very good.
>> GWorkspace is ifne to use, as are text application, as is Gorm or
>> ProjectCenter.
> 
> Arts and Cairo seem to be a lot slower than they need to be.  They don't
> appear to be using XFixes / XDamage to only update the modified parts of
> the window, which is a shame because this information is explicitly
> provided by the APIs in AppKit (these two extensions, used correctly,
> can make remote X11 much more responsive, as can double-buffering using
> server-side Pictures).
> 
> That said, I've watched my network monitor with remote X and it doesn't
> seem to be shifting much traffic.  The issue largely appears to be that
> it is using the xlib APIs which do no latency hiding, which means that
> it spends a lot of time waiting for round trips.  Even on a network with
> a few ms RTT this can become painfully slow since simple operations can
> require a few dozen round trips.
> 
> There isn't much that can be easily done about this, unfortunately. 
> Longer-term, the solution is to move to XCB, but the documentation for
> XCB is practically non-existent (on the plus side, the API is almost
> exactly the same as the protocol, so the protocol docs apply).
> 
> The first step towards doing this would be to check that GNUstep
> compiles with the new xlib which is built on top of XCB.  From this it
> is possible to do an incremental port.  This is worth doing long-term,
> since xlib is not going to be getting APIs for newer parts of the
> protocol much longer.
> 
>> One thing will be awful though: scrolling. I think GNUstep is quite
>> inefficient there, it makes a LOT of X11 calls, art is less affected
>> when it uses xshm. On a slower machine you will see that X11 can
>> sometimeseat up to 50% of your CPU for some operations..
> 
> I think the problem with this is that it uses client-side copying,
> rather than doing the operation on the server side.
> 

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.

Fred