Re: gui 'slow' with remote X ?

[address@hidden]

On 30 Nov., 19:17, Riccardo Mottola <mul...@ngi.it> wrote:
> ---------- Forwarded message ----------
> Date: 2008-11-28 20:37:06 +0100
>  From: Fred Kiefer <fredkie...@gmx.de>
> Subject: Re: gui 'slow' with remote X ?
>
> h...@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. Both the scrolling of
> the message area as wellas the message table are reasonably fast, no
> excessive jerkiness or delay.
> When on the same computer I stpart PRICE and siplay an image big
> enough so that it needs to scroll (an image sized about as big as my
> screen, so not an exceedingly big one either) and scroll (that means,
> dragging the scroll thumb and moving it up or down) it feels extremely
> jerky and blocky, even for small amounts (where the "new" image part
> is relatively small). It is clear that the new uncovered part needs to
> be tramsitted over the network.
>
> --Ric

What I did experience in mySTEP is the following issue:

Although the scrolled area is copied and the new area to become
visible
is set to be dirty, the vertical scroller is also be set dirty.

Unter certain circumstances, these dirty rects make a new rectangle
(unionRect)
that covers the whole view therefore asking it to redraw what already
has been moved by CopyArea...
This may result from the opaque-ancestor mechanism.

So it *might* be a bug not really noticeable on fast hardware.

Nikolaus