Bug 81175 – [chromium] Add overdraw metrics for texture uploads

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Dana Jansens]

[chromium] Add overdraw metrics for texture uploads

[Dana Jansens]

Created attachment 131982 [details]
Patch

[Dana Jansens]

I decided to track texture upload metrics instead of "painted pixels" or something.

It measures the number of bytes of textures uploaded to texture memory, and the amount of bytes avoided via paint culling.

[David Reveman]

So tracking uploads instead of painted pixels means we can't see the effect of per-tile painting in these metrics, right? I think that's good but it would be nice to have some additional metrics to track that. Maybe "InvalidatedPixels" and "PaintedPixels". "PaintedPixels" would be higher than "InvalidatedPixels" when per-tile painting is not used.

[Dana Jansens]

(In reply to comment #3)
> So tracking uploads instead of painted pixels means we can't see the effect of per-tile painting in these metrics, right? I think that's good but it would be nice to have some additional metrics to track that. Maybe "InvalidatedPixels" and "PaintedPixels". "PaintedPixels" would be higher than "InvalidatedPixels" when per-tile painting is not used.

Is the number of painted pixels something that we are going to optimize beyond turning on per-tile-painting? I had the impression that we are always going to paint all dirty tiles that are visible at all.

[Dana Jansens]

Splitting this CL up so changes to CCOverdrawMetrics/CCOcclusionTracker happen in 81222. Should make review easier.

[David Reveman]

(In reply to comment #4)
> (In reply to comment #3)
> > So tracking uploads instead of painted pixels means we can't see the effect of per-tile painting in these metrics, right? I think that's good but it would be nice to have some additional metrics to track that. Maybe "InvalidatedPixels" and "PaintedPixels". "PaintedPixels" would be higher than "InvalidatedPixels" when per-tile painting is not used.
> 
> Is the number of painted pixels something that we are going to optimize beyond turning on per-tile-painting? I had the impression that we are always going to paint all dirty tiles that are visible at all.

These metrics would help determine how much per-tile painting is buying us. I'm not aware of any worthwhile optimization beyond that.

[Dana Jansens]

Ok cool. I'll make a bug to add this.

[Dana Jansens]

Created attachment 132061 [details]
Patch

[Dana Jansens]

This changes the symantics of UpdatableTile::m_updateRect slightly.

To tell if a tile was updated
before: !m_updateRect.isEmpty()
now: !m_updateRect.isEmpty() && !m_updateCulled

[Adrienne Walker]

Comment on attachment 132061 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=132061&action=review

Looks good.  R=me.

> Source/WebCore/platform/graphics/chromium/TiledLayerChromium.cpp:66
> +    bool isDirtyForCurrentFrame() { return !m_dirtyRect.isEmpty() && (m_updateRect.isEmpty() || m_updateCulled); }

nit: can you add a comment to explain this expression?

[Dana Jansens]

Done. Thanks!

[Dana Jansens]

Created attachment 132160 [details]
Patch

[Dana Jansens]

Created attachment 132281 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 132281 [details]
Patch for landing

Clearing flags on attachment: 132281

Committed r111023: <http://trac.webkit.org/changeset/111023>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.