#1424 closed task (fixed)
html5: faster network layer, input devices, etc
Reported by: | Antoine Martin | Owned by: | alas |
---|---|---|---|
Priority: | major | Milestone: | 2.0 |
Component: | html5 | Version: | trunk |
Keywords: | Cc: |
Description
Follow up from #1341.
Video / paint:
- either fix broadway, or get native video decoding to play properly without buffering too much
process_interval
should not be hardcoded?
Network layer:
onmessage
should not copy bytes at a time (see ticket:1341#comment:12)- less wasteful process_xxxx_queue" timers scheduling
process_receive_queue
should not use recursion
Input devices:
- throttle tablet input events / #1390
Attachments (5)
Change History (11)
Changed 4 years ago by
Attachment: | test-slow-send.patch added |
---|
Changed 4 years ago by
Attachment: | html5-zerocopy.patch added |
---|
implement zero copy in network layer - only aggregate chunks if we have to, do it using fast set method
Changed 4 years ago by
Attachment: | html5-timers-managed.patch added |
---|
try to manage the timers and only use them as needed - actually makes things slower
Changed 4 years ago by
Attachment: | html5-timers-managed-v2.patch added |
---|
alternative implementation of managed timers
comment:1 Changed 4 years ago by
Status: | new → assigned |
---|
- r15183 merges the zero copy code (and removes some unused variables, more removed in r15185)
- r15184: don't queue draws, r15187: lower timer delay
We could also modify process_receive_queue
to only parse the "packet size", "packet flags" and "padding" when we get the full 8-byte header - small saving which would make the code harder to read. meh.
With these changes, testing with glxspheres at high res, the throughput and framerate are increased - but really not by much. And this is even more wasteful than before (running the timers at full speed), so r15188 switches to "on-demand" timers. (also a bit slower?)
Big question: how can we validate those changes better? We need reliable performance data to compare before and after, preferably using a real-world use case (not glxgears / glxspheres).. As some of these changes may actually make things worse.
comment:2 Changed 4 years ago by
- moving clipboard to its own ticket: #1461
- we try to clamp the windows to the browser's window area, but allow the user to move part of the window "off-screen" if they wish: r15241 - but there's a bug in the "draggable window" code, which is reporting coordinates out of range... and they get more and more out of range as we clamp the window, something is not getting updated somewhere
comment:3 Changed 4 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
Summary: | html5: use video, faster network layer, input devices, etc → html5: faster network layer, input devices, etc |
I am moving video support to #1463. (too late for this release)
Tablet devices should be handled better than before as of r15253 + r15255.
We normalize the wheel event values using the facebook code found here: normalizeWheel.js. And we try to send one event for each javascript wheel event we receive, unless those are very fine grained (from a tablet?).
With debug enabled, the Javascript console shows that on Linux I'm getting a delta of 120 per event with Firefox, and ~156 for google chrome..
We'll be able to handle this a lot better once we implement extended input device support (#173)
Links:
- javascript wheel events documentation
- wheel delta test page
@afarr: since we don't have a reliable way of measuring performance, the only thing to test in this ticket is likely to be the scrolling with various browsers / os / devices.
comment:4 Changed 4 years ago by
comment:6 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1424
make it easier to test slow network and packet aggregation in client receiver code