WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
93743
[chromium] Update HUD resources as a final step to drawing a frame
https://bugs.webkit.org/show_bug.cgi?id=93743
Summary
[chromium] Update HUD resources as a final step to drawing a frame
Dana Jansens
Reported
2012-08-10 14:16:37 PDT
[chromium] Update HUD resources as a final step to drawing a frame
Attachments
Patch
(5.78 KB, patch)
2012-08-10 14:19 PDT
,
Dana Jansens
no flags
Details
Formatted Diff
Diff
Patch
(10.19 KB, patch)
2012-08-15 12:33 PDT
,
Dana Jansens
no flags
Details
Formatted Diff
Diff
Patch
(9.64 KB, patch)
2012-08-20 09:10 PDT
,
Dana Jansens
no flags
Details
Formatted Diff
Diff
Patch
(9.60 KB, patch)
2012-08-20 09:55 PDT
,
Dana Jansens
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Dana Jansens
Comment 1
2012-08-10 14:19:22 PDT
Created
attachment 157808
[details]
Patch
Dana Jansens
Comment 2
2012-08-10 14:19:59 PDT
This needs tests, but I am wondering about feelings about this approach to solving
http://code.google.com/p/chromium/issues/detail?id=141920
Adrienne Walker
Comment 3
2012-08-13 10:16:49 PDT
Comment on
attachment 157808
[details]
Patch I think I'd really prefer not to add some step that applies to all layers. Updating resources that you have already put in quads also seems potentially fragile. It may work now, but it seems easy to break, and we have no HUD tests. I think the only information that you don't have immediately post-calcDraw is the screen space occlusion rects. My thought is that you can save all but those rects explicitly on the HUD layer right after calcDraw and then make the HUD layer the container for the screen space occlusion rects to get those right when it needs it during appendQuads since it goes last.
Dana Jansens
Comment 4
2012-08-15 12:33:55 PDT
Created
attachment 158616
[details]
Patch
Dana Jansens
Comment 5
2012-08-15 12:34:49 PDT
Here's a new proposal for ya! 1. Have the HUD layer save a pointer to itself on commit in the CCLTHI. 2. CCLTHI clears this pointer each commit to avoid staleness. 3. CCLTHI calls the HUD layer to update its texture just before it draws the frame.
Adrienne Walker
Comment 6
2012-08-15 16:26:28 PDT
Comment on
attachment 158616
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=158616&action=review
> Source/WebCore/platform/graphics/chromium/cc/CCHeadsUpDisplayLayerImpl.cpp:77 > + hostImpl->setHudLayer(this);
Can you move this to CCLayerTreeHost::finishCommitOnImplThread with the rest of the syncing code, clearing the hud layer pointer if it doesn't exist?
Dana Jansens
Comment 7
2012-08-16 09:40:17 PDT
Comment on
attachment 158616
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=158616&action=review
>> Source/WebCore/platform/graphics/chromium/cc/CCHeadsUpDisplayLayerImpl.cpp:77 >> + hostImpl->setHudLayer(this); > > Can you move this to CCLayerTreeHost::finishCommitOnImplThread with the rest of the syncing code, clearing the hud layer pointer if it doesn't exist?
The thing is CCLTH doesn't know the impl pointer unless we store it in the HUDLayer over there. This lets us avoid storing the Impl pointer on the non-impl tree anywhere.
James Robinson
Comment 8
2012-08-16 10:07:08 PDT
I think it's OK for one or both LTH's to know about the HUD layer. It's quite magical already.
Dana Jansens
Comment 9
2012-08-16 10:52:36 PDT
(In reply to
comment #8
)
> I think it's OK for one or both LTH's to know about the HUD layer. It's quite magical already.
Yeh, as it does in this patch. But I mean there's no link from HUDLayerChromium to CCHUDLayerImpl unless we store the impl layer's pointer in the HUDLayerChromium when we create the impl layer. Then the CCLTH could pull it out that way. But it seems more sketchy to me to store a pointer from Layer->LayerImpl as that's something we don't do ever now. Or we do something in TreeSychronizer, or do a tree walk to find the CCHUDLayerImpl by ID in CCLTH. Preferences?
Adrienne Walker
Comment 10
2012-08-17 16:13:04 PDT
(In reply to
comment #9
)
> (In reply to
comment #8
) > > I think it's OK for one or both LTH's to know about the HUD layer. It's quite magical already. > > Yeh, as it does in this patch. But I mean there's no link from HUDLayerChromium to CCHUDLayerImpl unless we store the impl layer's pointer in the HUDLayerChromium when we create the impl layer. Then the CCLTH could pull it out that way. > > But it seems more sketchy to me to store a pointer from Layer->LayerImpl as that's something we don't do ever now. > > Or we do something in TreeSychronizer, or do a tree walk to find the CCHUDLayerImpl by ID in CCLTH. > > Preferences?
A tree walk to find the layer by ID during commit seems reasonable. I'd rather not complicate TreeSynchronizer anymore.
Dana Jansens
Comment 11
2012-08-20 09:10:57 PDT
Created
attachment 159449
[details]
Patch
Dana Jansens
Comment 12
2012-08-20 09:55:56 PDT
Created
attachment 159459
[details]
Patch Oh, CC header paths have changed. I made a layer tree walk in CCLTH to push over the hud layer pointer as requested\!
Adrienne Walker
Comment 13
2012-08-20 10:59:29 PDT
Comment on
attachment 159459
[details]
Patch R=me.
WebKit Review Bot
Comment 14
2012-08-20 11:23:24 PDT
Comment on
attachment 159459
[details]
Patch Clearing flags on attachment: 159459 Committed
r126046
: <
http://trac.webkit.org/changeset/126046
>
WebKit Review Bot
Comment 15
2012-08-20 11:23:28 PDT
All reviewed patches have been landed. Closing bug.
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