Bug 66430 - [chromium] Remove LayerRendererChromium references from the LayerChromium tree
Summary: [chromium] Remove LayerRendererChromium references from the LayerChromium tree
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: Adrienne Walker
URL:
Keywords:
Depends on: 66065 66432 66433 66434 66435 66439 66807
Blocks: 67438
  Show dependency treegraph
 
Reported: 2011-08-17 16:46 PDT by Adrienne Walker
Modified: 2011-09-02 10:35 PDT (History)
4 users (show)

See Also:


Attachments
Patch (26.46 KB, patch)
2011-09-01 12:46 PDT, Adrienne Walker
no flags Details | Formatted Diff | Diff
Patch (26.45 KB, patch)
2011-09-01 12:51 PDT, Adrienne Walker
no flags Details | Formatted Diff | Diff
Patch (26.47 KB, patch)
2011-09-01 16:26 PDT, Adrienne Walker
jamesr: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrienne Walker 2011-08-17 16:46:02 PDT
LayerRendererChromium is a compositor thread-side class that currently both LayerChromium- and CCLayerImpl-derived classes access, mostly to get at the context and settings.  LayerChromium::layerRenderer() and LayerChromium::layerRendererContext() should both be removed, once alternate functionality is put in place for all of the LayerChromium-derived classes.
Comment 1 Adrienne Walker 2011-09-01 12:46:27 PDT
Created attachment 106011 [details]
Patch
Comment 2 Adrienne Walker 2011-09-01 12:48:26 PDT
This needs bug 66807 to land before this patch will apply, so leaving the review flag off.

nduca: I'd love if you could sanity check what I did in WebGLLayerChromium to punch through the compositor context in the single-threaded case.  I used a bunch of functions that looked like they were temporary and would eventually go away.  If you have a better idea about how to do this, I'll take suggestions.  :)
Comment 3 Adrienne Walker 2011-09-01 12:51:02 PDT
Created attachment 106013 [details]
Patch
Comment 4 Nat Duca 2011-09-01 15:57:56 PDT
Comment on attachment 106013 [details]
Patch

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

Me <3's this patch.

> Source/WebCore/platform/graphics/chromium/WebGLLayerChromium.cpp:152
> +    return 0;

ASSERT(false); CRASH()
Comment 5 Adrienne Walker 2011-09-01 16:26:15 PDT
Created attachment 106059 [details]
Patch
Comment 6 James Robinson 2011-09-01 17:00:36 PDT
Comment on attachment 106059 [details]
Patch

R=me
Comment 7 Nat Duca 2011-09-02 00:19:09 PDT
Comment on attachment 106059 [details]
Patch

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

> Source/WebCore/platform/graphics/chromium/WebGLLayerChromium.cpp:149
> +#if USE(THREADED_COMPOSITING)

Sorry for the late breaking feedback, but can we do this as a runtime check? E.g. layerTreeHost()->settings().useThreadedCompositing
Comment 8 Adrienne Walker 2011-09-02 09:10:10 PDT
(In reply to comment #7)
> (From update of attachment 106059 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=106059&action=review
> 
> > Source/WebCore/platform/graphics/chromium/WebGLLayerChromium.cpp:149
> > +#if USE(THREADED_COMPOSITING)
> 
> Sorry for the late breaking feedback, but can we do this as a runtime check? E.g. layerTreeHost()->settings().useThreadedCompositing

Ah, you're totally right.  I'll fix that when landing.
Comment 9 Adrienne Walker 2011-09-02 10:35:10 PDT
Committed r94431: <http://trac.webkit.org/changeset/94431>