Bug 72630 - [Chromium] Calls to paintContentsIfDirty() and updateCompositorResources() should be balanced.
Summary: [Chromium] Calls to paintContentsIfDirty() and updateCompositorResources() sh...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: David Reveman
URL:
Keywords:
Depends on:
Blocks: 71388
  Show dependency treegraph
 
Reported: 2011-11-17 10:15 PST by David Reveman
Modified: 2011-11-17 16:49 PST (History)
5 users (show)

See Also:


Attachments
Patch (8.60 KB, patch)
2011-11-17 10:44 PST, David Reveman
no flags Details | Formatted Diff | Diff
Patch (10.87 KB, patch)
2011-11-17 11:50 PST, David Reveman
no flags Details | Formatted Diff | Diff
Patch (14.49 KB, patch)
2011-11-17 14:03 PST, David Reveman
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Reveman 2011-11-17 10:15:32 PST
Layer property changes during paintContent() can leave the layer in an invalid state as paintContentsIfDirty() has been called without a matching updateCompositorResources() call. Removing conditionals around these calls ensure they are balanced.

This change can result in unnecessary uploads but that can be properly solved using this change: https://bugs.webkit.org/show_bug.cgi?id=72192
Comment 1 David Reveman 2011-11-17 10:44:06 PST
Created attachment 115620 [details]
Patch
Comment 2 Adrienne Walker 2011-11-17 11:44:27 PST
Comment on attachment 115620 [details]
Patch

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

I wish there were some better way to assert that this never happened in practice.  Do you think it'd be a good idea to store the compositor frame that is being painted in TiledLayerChromium::prepareToUpdate and assert/early-out if the frame number is different during TiledLayerChromium::updateCompositorResources?

> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:-339
> -    if (layer->drawsContent())
> -        layer->paintContentsIfDirty();

Can you leave the drawsContent() check both here and in updateCompositorResources? Otherwise, you're going to trip asserts like the ASSERT(drawsContent()) in VideoLayerChromium::updateCompositorResources.
Comment 3 David Reveman 2011-11-17 11:50:09 PST
Created attachment 115642 [details]
Patch
Comment 4 David Reveman 2011-11-17 11:54:15 PST
(In reply to comment #2)
> (From update of attachment 115620 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=115620&action=review
> 
> I wish there were some better way to assert that this never happened in practice.  Do you think it'd be a good idea to store the compositor frame that is being painted in TiledLayerChromium::prepareToUpdate and assert/early-out if the frame number is different during TiledLayerChromium::updateCompositorResources?
> 
> > Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:-339
> > -    if (layer->drawsContent())
> > -        layer->paintContentsIfDirty();
> 
> Can you leave the drawsContent() check both here and in updateCompositorResources? Otherwise, you're going to trip asserts like the ASSERT(drawsContent()) in VideoLayerChromium::updateCompositorResources.

Realized this just after uploading the previous patch. I think my new patch handles this properly. We need to make sure that if one of these calls are made the other needs to be made as well. It will be easy to avoid both calls when 72192 has landed.
Comment 5 James Robinson 2011-11-17 12:19:22 PST
Comment on attachment 115642 [details]
Patch

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

> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:338
>  static void paintContentsIfDirty(LayerChromium* layer)
>  {
> -    if (layer->drawsContent())
> -        layer->paintContentsIfDirty();
> +    layer->paintContentsIfDirty();

this helper isn't useful any more, can you just inline it?
Comment 6 James Robinson 2011-11-17 13:02:11 PST
Does https://bugs.webkit.org/show_bug.cgi?id=71038 simplify this?
Comment 7 David Reveman 2011-11-17 14:03:38 PST
Created attachment 115671 [details]
Patch
Comment 8 David Reveman 2011-11-17 14:04:19 PST
(In reply to comment #5)
> (From update of attachment 115642 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=115642&action=review
> 
> > Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:338
> >  static void paintContentsIfDirty(LayerChromium* layer)
> >  {
> > -    if (layer->drawsContent())
> > -        layer->paintContentsIfDirty();
> > +    layer->paintContentsIfDirty();
> 
> this helper isn't useful any more, can you just inline it?

Fixed.
Comment 9 David Reveman 2011-11-17 14:10:21 PST
(In reply to comment #6)
> Does https://bugs.webkit.org/show_bug.cgi?id=71038 simplify this?

That change is great as it makes this fix less likely to cause a performance regression.
Comment 10 James Robinson 2011-11-17 14:21:17 PST
Comment on attachment 115671 [details]
Patch

Looks great, R=me. Could you let Enne check it over before landing?
Comment 11 Adrienne Walker 2011-11-17 14:56:01 PST
Comment on attachment 115671 [details]
Patch

LGTM
Comment 12 WebKit Review Bot 2011-11-17 16:49:17 PST
Comment on attachment 115671 [details]
Patch

Clearing flags on attachment: 115671

Committed r100702: <http://trac.webkit.org/changeset/100702>
Comment 13 WebKit Review Bot 2011-11-17 16:49:22 PST
All reviewed patches have been landed.  Closing bug.