Avoid invalidating Graphics objects if they don't "change".

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
4 years ago
3 years ago

People

(Reporter: mbx, Assigned: tschneider)

Tracking

({perf})

Dependency tree / graph

Details

(Whiteboard: fb)

(Reporter)

Description

4 years ago
The FB player redraws the graphics object of the seek bar on every frame. We end up invalidating the Shape it belongs to, remoting the graphics object and eventually invalidating and repainting the entire stage in the GFX backend. We can fix some of the effects of this behaviour in the GFX world, but it would be nice to optimize this on the player side.
Ok, time to put my idea on this in writing:

1. When Graphics#clear is called, we could keep the old shape data around instead of discarding it.

2. For each drawing command after that, we check if it matches what we have in the old shape data at that point and just move an offset indicating how much of the shape data is valid again (which naturally starts out at 0).

3a. If the valid-offset is still below the old shape data length and we encounter a command that doesn't match the data, we discard the rest and mark the shape as invalid as per usual.

3b. If the valid-offset reaches the old shape data length, we mark the shape as unchanged.

At this point, we should be done for cases like the fb player ui controls.

However, another scenario after 3b. is possible: additional drawing commands being added. This then becomes the same scenario as if Graphics#clear had never been called, but new commands had been added.

We can mark the shape as invalid-pure-addition. I.e., we tell the GFX side that there's no need to completely discard the texture. Instead, the additional drawing commands can be applied to the existing texture in a purely additional fashion.

This last scenario obviously only becomes interesting if the shape is cached. Ideally, it should be in many cases, though.
Blocks: 1110300
Keywords: perf
Blocks: 1120590
No longer blocks: 1110300
(Assignee)

Updated

4 years ago
Assignee: nobody → schneider
Blocks: 1037580
No longer blocks: 1120590
Blocks: 1120590
Let's re-evaluate this before release. It's a plain optimization that we can land fairly late if we deem it safe enough. If not, we don't.
Blocks: 1038057
No longer blocks: 1037580
Product: Firefox → Firefox Graveyard
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.