[Webkit-unassigned] [Bug 67341] Scissor rect optimization for chromium compositor

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=67341





--- Comment #5 from Nat Duca <nduca at chromium.org>  2011-09-01 15:03:23 PST ---
(From update of attachment 105864)
Definitely pull this apart into more and smaller patches. There shouldn't be any visualization in this patch, just the logic to compute changed-ness.

For the enable flag, you can put a bool on CCSettings, initialize it to false in the constructor, then for your testing purposes set it to true. We can figure out how to turn it on officially later.

It feels to me that the "setNeedsCommitBecauseXXX" approach is quite fragile. It seems to me that there is a fair amount of fragility pushed into the layer system with this approach, as each layer has to very-carefully specify what kind of change is happening.

Did you give any thought to doing this as a preprocessing step on a QuadList?

E.g. make a modified version drawLayers that walks the tree but instead of drawing, for every drawCall, puts a quad into a QuadBuffer:
struct DrawQuadInfo {FloatQuad screenspaceQuad (with depth), bool textureChanged, FloatQuad changedRectInsideTextureProjectedToScreenspace}

Then, before drawlayers, build this quadlist. Remember the last frame's quadlist as well. Walk the list, if any quads have moved or their textures changed, use that to derive screenspace scissor rect. Then set the scissor and run the drawLayers.

Webkit todos are ≈FIXME. E.g. // FIXME: blahblahblah. TODO(username) is chrome style.

If you were going to stick with the setNeedsCommitBecause approach, maybe use an enum?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.