Closed Bug 1110043 Opened 10 years ago Closed 8 years ago

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

Categories

(Firefox Graveyard :: Shumway, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: mbx, Assigned: tschneider)

References

Details

(Keywords: perf, Whiteboard: fb)

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: shumway-fb2
Keywords: perf
No longer blocks: shumway-fb2
Assignee: nobody → schneider
No longer blocks: shumway-jw2
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: shumway-1.0
No longer blocks: shumway-m4
Product: Firefox → Firefox Graveyard
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.