Bug 82569 - [chromium] Ensure framebuffer exists at the start of beginDrawingFrame.
Summary: [chromium] Ensure framebuffer exists at the start of beginDrawingFrame.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Michal Mocny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-28 21:11 PDT by Michal Mocny
Modified: 2012-03-29 13:36 PDT (History)
4 users (show)

See Also:


Attachments
Patch (11.09 KB, patch)
2012-03-28 21:12 PDT, Michal Mocny
no flags Details | Formatted Diff | Diff
Patch (12.15 KB, patch)
2012-03-28 21:20 PDT, Michal Mocny
no flags Details | Formatted Diff | Diff
Patch (11.98 KB, patch)
2012-03-29 12:16 PDT, Michal Mocny
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Mocny 2012-03-28 21:11:37 PDT
[chromium] Ensure framebuffer exists at the start of beginDrawingFrame.
Comment 1 Michal Mocny 2012-03-28 21:12:11 PDT
Created attachment 134491 [details]
Patch
Comment 2 Michal Mocny 2012-03-28 21:14:48 PDT
Comment on attachment 134491 [details]
Patch

If we ensure that a framebuffer exists before beginning to draw a frame, we need not have clients explicitly manage it, and we can be sure it is done on the right thread.

This is also how it will work once it recreates itself of first use, so it is good practice.

We need not discard a recreated framebuffer, because GpuMemoryManager will send another allocation suggesting to discard it.
Comment 3 Nat Duca 2012-03-28 21:17:04 PDT
Comment on attachment 134491 [details]
Patch

LGTM
Comment 4 Michal Mocny 2012-03-28 21:18:23 PDT
Comment on attachment 134491 [details]
Patch

one sec, patch to remove public methods as they are no longer needed inc
Comment 5 Michal Mocny 2012-03-28 21:20:46 PDT
Created attachment 134493 [details]
Patch
Comment 6 Nat Duca 2012-03-28 22:35:30 PDT
Comment on attachment 134493 [details]
Patch

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

> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:64
> +class FakeDrawableCCLayerImpl: public CCLayerImpl {

Not sure what these root layer changes are for...?

> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:196
> +    m_layerRendererChromium.beginDrawingFrame();

Where's the expectation that we called ensure?
Comment 7 Michal Mocny 2012-03-29 04:50:38 PDT
Comment on attachment 134493 [details]
Patch

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

>> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:64
>> +class FakeDrawableCCLayerImpl: public CCLayerImpl {
> 
> Not sure what these root layer changes are for...?

We assert that we do not have a null root layer in beginDrawingFrame.

>> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:196
>> +    m_layerRendererChromium.beginDrawingFrame();
> 
> Where's the expectation that we called ensure?

Right below, before this line we EXPECT that isFramebufferDiscarded returns true, after this line it returns false.
Comment 8 Nat Duca 2012-03-29 09:53:05 PDT
Comment on attachment 134493 [details]
Patch

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

Got it. Makes sense. Still lgtm.

>>> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:196
>>> +    m_layerRendererChromium.beginDrawingFrame();
>> 
>> Where's the expectation that we called ensure?
> 
> Right below, before this line we EXPECT that isFramebufferDiscarded returns true, after this line it returns false.

So you might want to put before this line expect no framebuffer
Comment 9 James Robinson 2012-03-29 10:33:10 PDT
Comment on attachment 134493 [details]
Patch

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

R=me. Could use some small cleanup before landing.

> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.h:168
> +    friend class LayerRendererGpuMemoryAllocationChangedCallbackAdapter;

this adapter confuses me. It adapts the call onSwapBuffersComplete() to onSwapBuffersComplete(). Why doesn't LRC just implement Extensions3DChromium::SwapBuffersCompleteCallbackCHROMIUM ?

>>> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:64
>>> +class FakeDrawableCCLayerImpl: public CCLayerImpl {
>> 
>> Not sure what these root layer changes are for...?
> 
> We assert that we do not have a null root layer in beginDrawingFrame.

This class appears to do nothing but expose the constructor (which is protected). However there's a ::create() function that does exactly what you want. Just make your test client have an OwnPtr<CCLayerImpl> and you can test the real class instead of this somewhat silly fake

> Source/WebKit/chromium/tests/LayerRendererChromiumTest.cpp:71
> +    FakeLayerRendererChromiumClient() : m_setFullRootLayerDamageCount(0), m_rootLayer(1) { }

one statement per line
Comment 10 Michal Mocny 2012-03-29 10:41:25 PDT
Comment on attachment 134493 [details]
Patch

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

>> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.h:168
>> +    friend class LayerRendererGpuMemoryAllocationChangedCallbackAdapter;
> 
> this adapter confuses me. It adapts the call onSwapBuffersComplete() to onSwapBuffersComplete(). Why doesn't LRC just implement Extensions3DChromium::SwapBuffersCompleteCallbackCHROMIUM ?

I assume you meant to type onMemoryAllocationChanged, and the main reason was to not need to expose extensions3dchromium in the header, and was copying the style of onSwap...
I can make the change if that is preferred.
Comment 11 James Robinson 2012-03-29 10:46:08 PDT
Right, the other one. I think it's fine for LayerRendererChromium to know about Extensions, the point of LRC is to implement GraphicsContext3D-based functionality.
Comment 12 Nat Duca 2012-03-29 11:02:32 PDT
I think also that the E3D callback model takes ownership of the callback ptr. We dont want G3CD deleting the lrc :)
Comment 13 Michal Mocny 2012-03-29 12:16:18 PDT
Created attachment 134639 [details]
Patch
Comment 14 WebKit Review Bot 2012-03-29 13:36:19 PDT
Comment on attachment 134639 [details]
Patch

Clearing flags on attachment: 134639

Committed r112568: <http://trac.webkit.org/changeset/112568>
Comment 15 WebKit Review Bot 2012-03-29 13:36:36 PDT
All reviewed patches have been landed.  Closing bug.