xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Custom Query (2683 matches)


Show under each result:

Results (13 - 15 of 2683)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Ticket Resolution Summary Owner Reporter
#21 fixed jitter on link causes keys to repeat Antoine Martin Antoine Martin

Solutions proposed:

  • doing the key repeat client-side - this does not seem to be a workable solution, it is likely to break applications which are currently working just fine
  • a better approach would be to require the client to confirm the key repeat within a certain amount of time: that way we can keep the key pressed on the server side, but we unpress it if we don't receive a "key-still-pressed" from the client in time. This allows us to maintain a consistent server-side state but we can also detect jitter on the line and take appropriate counter measures. (if we do eventually get the "key-still-pressed" packet after the timeout, we just press it again). The downside is that the line jitter will probably still cause keys to be pressed more than once (probably twice), just not dozens of times as it is now. Difficulty comes from the fact that the key-repeat delay is configurable and that it may well be shorter than the connection's transmit time when accounting for jitter.. And that we would need to communicate this delay to the client, and that those "key-still-pressed" messages waste precious bandwidth (although hardly more so than the pure client-side option)
  • letting the server increase the key repeat delay - we probably would need some kind of timing information with the packets so the server can have an idea of latency (this may be worth having in any case)
  • sending key events ahead of anything else (even mouse motion?) - this would not solve all cases, but work for cases where the high latency is caused by xpra packets
#24 fixed network read loop is highly inefficient Antoine Martin Antoine Martin

Whenever we read a bit of data from the socket (sometimes as small as just one character!) we schedule the main loop to call _handle_read. When it actually fires there may only be (sometimes less than) one real packet waiting there, yet it will fire as many times as the socket read loop originally fired. We want to ensure we don't schedule it again if it is already pending, this should save a lot of context switches and reduce load significantly. Using an atomic loop counter should probably be enough to achieve this.

#25 fixed xpra window icons can be far too big Antoine Martin Antoine Martin

During testing on android (and sending icons as png as per r176) I noticed that some window icons, sent as "icon" as part of the window metadata can be up to 256x256 in size. Most of the time these are only used as a small icon in the window's title bar and in the task manager. Also, as far as I know there are no constraints on the size which will be accepted by the window manager. Therefore, to try to minimize the use of bandwidth we should scale those down to a more reasonable size before sending, maybe 48x48?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Note: See TracQuery for help on using queries.