WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
91555
[chromium] Ubercomp: clean up CCRenderer interface
https://bugs.webkit.org/show_bug.cgi?id=91555
Summary
[chromium] Ubercomp: clean up CCRenderer interface
Alexandre Elias
Reported
2012-07-17 16:31:42 PDT
[chromium] Ubercomp: clean up CCRenderer interface
Attachments
Patch
(14.13 KB, patch)
2012-07-17 16:41 PDT
,
Alexandre Elias
no flags
Details
Formatted Diff
Diff
Patch
(14.13 KB, patch)
2012-07-18 13:49 PDT
,
Alexandre Elias
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Alexandre Elias
Comment 1
2012-07-17 16:41:04 PDT
Created
attachment 152873
[details]
Patch
Alexandre Elias
Comment 2
2012-07-17 16:41:24 PDT
This is an small cleanup to reduce boilerplate in the ubercomp implementation. When CCHeadsUpDisplay is better integrated into LayerRendererChromium, we should make private finishDrawingFrame() as well.
Dana Jansens
Comment 3
2012-07-18 06:41:05 PDT
Comment on
attachment 152873
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=152873&action=review
> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:368 > + renderPass->targetSurface()->damageTracker()->didDrawDamagedArea();
This won't be able to stay here obviously, once targetSurface() is gone. So if we are going to do this, we have to guarantee that every render pass given to drawFrame() is actually drawn. I'm not sure that this is going to make our lives easier.. I'm currently adding another piece to the code in CCLTHI::drawLayers() that would then go here. But it really belongs there. CCLTHI manages the RenderPasses, LRC just draws them. So overall, I feel like this is not going to help us and isn't worth removing one method from the API. :/
Alexandre Elias
Comment 4
2012-07-18 13:38:29 PDT
For ubercomp, I was going to have to stash away pointers to the renderpasses as they came in, reconstruct the render pass list, and then do the actual work in finishDrawingFrame(). It seems to me that the one-at-a-time model is an implementation detail of OpenGL. Why shouldn't we make sure that the only renderpasses sent to CCRenderer will be actually drawn; that seems like a good idea anyway? We can still do some work on the side in CCLTHI; I'm fine with moving the didDrawDamaged area back there in a loop over the render passes.
Alexandre Elias
Comment 5
2012-07-18 13:49:40 PDT
Created
attachment 153082
[details]
Patch Move didDrawDamagedArea back to LTHI
Adrienne Walker
Comment 6
2012-07-18 14:28:32 PDT
Comment on
attachment 153082
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=153082&action=review
R=me.
> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:555 > + m_layerRenderer->drawFrame(frame.renderPasses, m_rootScissorRect); > + if (m_headsUpDisplay->enabled(settings())) > + m_headsUpDisplay->draw(this); > + m_layerRenderer->finishDrawingFrame();
It's a little weird to me to have this asymmetric finish function without an exposed begin, but I understand that you need to draw some extra stuff in the frame here. The heads up display is a little bit of a wart, and I'm not sure if it should be generating quads or be completely contained within LRC or something else. Refactoring for the future, I guess.
WebKit Review Bot
Comment 7
2012-07-18 15:33:19 PDT
Comment on
attachment 153082
[details]
Patch Clearing flags on attachment: 153082 Committed
r123033
: <
http://trac.webkit.org/changeset/123033
>
WebKit Review Bot
Comment 8
2012-07-18 15:33:32 PDT
All reviewed patches have been landed. Closing bug.
Tony Chang
Comment 9
2012-07-19 10:17:36 PDT
Reverted
r123036
for reason: Triggers some DCHECKs in Chromium browser_tests Committed
r123120
: <
http://trac.webkit.org/changeset/123120
>
Dana Jansens
Comment 10
2012-07-19 10:20:18 PDT
Comment on
attachment 153082
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=153082&action=review
>> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHostImpl.cpp:555 >> + m_layerRenderer->finishDrawingFrame(); > > It's a little weird to me to have this asymmetric finish function without an exposed begin, but I understand that you need to draw some extra stuff in the frame here. The heads up display is a little bit of a wart, and I'm not sure if it should be generating quads or be completely contained within LRC or something else. Refactoring for the future, I guess.
Making quads I think so a child renderer can display a hud.
Nate Chapin
Comment 11
2012-07-19 10:37:33 PDT
(In reply to
comment #9
)
> Reverted
r123036
for reason: > > Triggers some DCHECKs in Chromium browser_tests > > Committed
r123120
: <
http://trac.webkit.org/changeset/123120
>
The ChangeLog got mangled, it wasn't this bug that got reverted.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug