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)
this patch combines the new-override-redirect with the window's draw packet
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.
Probably not worth doing, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/76