xpra icon
Bug tracker and wiki

Opened 9 years ago

Closed 8 years ago

#76 closed enhancement (invalid)

try to minimize round trips: send pixel data with new override-redirect windows

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.4
Component: server Version:
Keywords: Cc:


On high latency links, the number of round trips required can cause the UI to look sluggish.

The server currently sends a "new-override-redirect" or "new-window" packet, the client then creates the window.

For override redirect windows, the damage data is sent in the next packet. The pixel data could be combined to ensure the window's contents are available as soon as it is shown.

For regular windows the server waits for the client's "map-window" event to actually configure it and make it visible (using the client's specified coordinates and size) and then requests the damage data.
This one is more difficult: we could pre-configure the window and send the pixel data with the "new-window" packet, but if the client somehow maps the window to a different coordinates or size, the response will require the window to be moved/resized and the new damage data to be sent... (which is actually worse)

Attachments (1)

xpra-send_new_window_pixels.patch (4.8 KB) - added by Antoine Martin 9 years ago.
this patch combines the new-override-redirect with the window's draw packet

Download all attachments as: .zip

Change History (4)

Changed 9 years ago by Antoine Martin

this patch combines the new-override-redirect with the window's draw packet

comment:1 Changed 9 years ago by Antoine Martin

Milestone: 0.0.7.x0.2
Owner: changed from Antoine Martin to Antoine Martin
Status: newaccepted

comment:2 Changed 8 years ago by Antoine Martin

Milestone: 0.20.4

Looking at this again and I can't understand my earlier reasoning, the server does this:

        self._do_send_new_window_packet("new-override-redirect", window, geometry, properties)
        (_, _, w, h) = geometry
        self._damage(window, 0, 0, w, h)

So the window's pixels will be sent in the next packet after the "new-window" packet.
The only case where this would make a difference is when the link is already saturated and window batching is in place: the pixels would then get delayed a little bit...

It would be good to get feedback from those experiencing this issue regularly before doing anything about it... so delaying for now.

comment:3 Changed 8 years ago by Antoine Martin

Resolution: invalid
Status: acceptedclosed

Probably not worth doing, closing.

Note: See TracTickets for help on using tickets.