xpra icon
Bug tracker and wiki

Opened 13 months ago

Last modified 9 months ago

#1700 assigned defect

faster damage processing - bandwidth constraints handling

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 3.1
Component: encodings Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Follow up from #999. These classes are becoming complicated and slow.

TODO:

  • run profiling again
  • merge video source? (we never use window source on its own anyway)
  • support multiple video regions?
  • cythonize, use strongly typed and faster "deque":Ring buffers in Python/Numpy
  • pre-calculate more values: ECU "engine map" like
  • more gradual refresh when under bandwidth constraints and at low quality: the jump from lossy to lossless can use up too much bandwidth, maybe refresh first at 80% before doing true lossless
  • use more bandwidth? (macos client could use more quality?)
  • slowly updating windows should be penalized less
  • don't queue more frames for encoding after a congestion event (ok already?)
  • maybe keep track of the refresh compressed size?

See also #920: some things could be made faster on the GPU..

Attachments (1)

encoding-selection.png (236.2 KB) - added by Antoine Martin 9 months ago.
profiling encoding selection

Download all attachments as: .zip

Change History (8)

comment:1 Changed 13 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned
Summary: faster damage processingfaster damage processing - bandwidth constraints handling

comment:2 Changed 13 months ago by Antoine Martin

Description: modified (diff)

comment:3 Changed 13 months ago by Antoine Martin

Description: modified (diff)

See also #1761

Last edited 11 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 10 months ago by Antoine Martin

See also ticket:1769#comment:1 : maybe we should round up all screen updates to ensure we can always use color subsampling and video encoders? Or only past a certain size to limit the cost?

Changed 9 months ago by Antoine Martin

Attachment: encoding-selection.png added

profiling encoding selection

comment:5 Changed 9 months ago by Antoine Martin

After much profiling, it turns out that encoding selection is actually pretty fast already:
profiling encoding selection
And so we're better off spending extra time choosing the correct encoding, instead of trying to save time there: r18669.
Other micro improvements: r18667, r18668

See also ticket:1299#comment:6, we seem to be processing the damage events fast enough (~0.25ms for do_damage), but maybe we're scheduling things too slowly when we get those damage storms?

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 9 months ago by Antoine Martin

Milestone: 2.33.0

For the record, I've used this command to generate the call graphs:

python2 ./tests/scripts/pycallgraph -i damage -- start --start-child="xterm -ls" --no-daemon

Minor related fix: r18685.

Re-scheduling as the profiling has shown that this is not a huge overhead after all.

comment:7 Changed 9 months ago by Antoine Martin

Milestone: 3.03.1
Note: See TracTickets for help on using tickets.