+++ This bug was initially created as a clone of Bug #1017389 +++ This bug is created based on Bug 1017389 Comment 9. crystallskull does not use HwComposer. crystalskull is a application in gaia. It uses WebGL for drawing. The app shows only WebGL canvas except status bar. This kind of very simple application should use HwComposer. But status bar add a lot of extra rendering area. It causes flame device's HwComposer quit rendering.

HwComposer rendering reduce cpu usage and compositor thread locking compared to OpenGL composition. HwComposer usage could improve the app's rendering performance. It is important for game using WebGL.

Nominate to b2g-v1.4. It could affect WebGL game's performance and power usage.

layer dump of crystal app on master flame.

This over paining added when showing status bar is very bad for performance in general.

As in Bug 1017389 Comment 9, "crystallskull + status bar" rendering result in "2.9 * actual frame buffer area size" rendering. It is insane. "crystallskull" part has only one WebGL canvas layer. starus bar is just small area on the display.

Sotaro, Here is HWC layer list of Crystal Skull frame: HWC layer[0]::ThebesLayer: dst=[0 30 480 800] src=[0 0 30 480 800] Tr=0 Blend=0x100 HWC layer[1]::ColorLayerComposite: dst=[0 30 480 800] src=[0 0 480 770] Color=ffffffff Blend=0x100 HWC layer[2]::CanvasLayerComposite: dst=[0 30 480 800] src=[0 0 320 513] Tr=2 Blend=0x105 HWC layer[3]::ThebesLayer: dst=[0 0 480 30] src=[0 0 480 30] Tr=0 Blend=0x100 H/W Composition failed As Color Layer is just a solid color, no RGBA data fetching is involved. So HAL does not count Color layer in total RGBA render area, so actually it is (1.9 x FB area), which is more than threshold limit of HWC (which is 1.5 x FB area) on non-H/W overlay device. If we see the layer configuration in this frame. HWC layer[0] is totally hidden under opaque content layer[1], so it is invisible but still it is sent for Composition, which does not make sense. So we have 2 possible ways to fix it: 1. Fix it in the rendering phase (painting). Layer[0] should not be in layer tree sent to Compositor. OR its GetEffectiveVisibleRegion() should return empty, so that it will not be included in composition as per check: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#203 . 2. Even if we get such a hidden layer. HwComposer2D should have a logic, not to include it in the created HWC layer list, which is sent to HWC HAL. BTW, SurfaceFlinger does not include such a hidden layer in HWC layer list. What do you say ?

What is the power usage issue here? Please provide data.

Oh and - not blocking because Crystal Skull isn't a partner app.

(In reply to Sushil from comment #6) > Sotaro, > > Here is HWC layer list of Crystal Skull frame: > HWC layer[0]::ThebesLayer: dst=[0 30 480 800] src=[0 0 30 480 800] Tr=0 > Blend=0x100 > HWC layer[1]::ColorLayerComposite: dst=[0 30 480 800] src=[0 0 480 770] > Color=ffffffff Blend=0x100 > HWC layer[2]::CanvasLayerComposite: dst=[0 30 480 800] src=[0 0 320 513] > Tr=2 Blend=0x105 > HWC layer[3]::ThebesLayer: dst=[0 0 480 30] src=[0 0 480 30] Tr=0 Blend=0x100 > H/W Composition failed > > As Color Layer is just a solid color, no RGBA data fetching is involved. So > HAL does not count Color layer in total RGBA render area, so actually it is > (1.9 x FB area), which is more than threshold limit of HWC (which is 1.5 x > FB area) on non-H/W overlay device. If we see the layer configuration in > this frame. HWC layer[0] is totally hidden under opaque content layer[1], so > it is invisible but still it is sent for Composition, which does not make > sense. > > So we have 2 possible ways to fix it: > 1. Fix it in the rendering phase (painting). Layer[0] should not be in layer > tree sent to Compositor. OR its GetEffectiveVisibleRegion() should return > empty, Does the hw compositor side rendering work correctly by the above?

(In reply to Sushil from comment #6) > > 2. Even if we get such a hidden layer. HwComposer2D should have a logic, not > to include it in the created HWC layer list, which is sent to HWC HAL. BTW, > SurfaceFlinger does not include such a hidden layer in HWC layer list. > > What do you say ? I am not sure if it is possible on Compositor. It might be a role of display list. BenWa, can you comment to the above question?

Sotaro, Option 1 needs change in the painting phase (Layer tree formation). Option 2 needs change in HwcComposer2D. In comment 9, which option are you referring to? For testing Option 2, I need to make change in HwcComposer2D and verify.

The displaylist isn't propagated to the compositor. Option 2 sounds like bug 981732 which is in the tree.

Sotaro, the bug 981732 covers only full screen use case, I can extend it to non-full screen use cases which is Option 2 (mentioned in Comment 6). So are we planning to go with Option 2 in this bug ? Benwa, is it possible to fix it in the painting phase (layer tree formation) ?

Doing this kind of optimization in the HWC isn't ideal but we want to avoid doing this regardless of where we composite. Really we would want to do global culling before compositing regardless if we use HWC/OGL or even D3D. Regardless we should fix as much as possible during layer tree building. This should deal with most cases *except* async layer transform where only the compositor can perform the culling.

(In reply to Sushil from comment #11) > Sotaro, > > Option 1 needs change in the painting phase (Layer tree formation). > Option 2 needs change in HwcComposer2D. > > In comment 9, which option are you referring to? For testing Option 2, I > need to make change in HwcComposer2D and verify. Sorry, I just seems to misunderstand the Option1. Did you said color layer should not be created by an application? I think that this should be fixed around displaylist creation like comment 12. > 1. Fix it in the rendering phase (painting). Layer[0] should not be in layer > tree sent to Compositor. OR its GetEffectiveVisibleRegion() should return > empty,

> Did you said color layer > should not be created by an application? I think that this should be fixed > around displaylist creation like comment 12. > No, I was pointing to Layer[0] (Thebes layer) as per Comment 6. It seems to be a potential issue in the logic used during layer tree creation and defining the visible region of layer[0]. It is totally hidden under layer[1] (Color layer), so ideally the effective visible region of layer[0] should be Empty OR layer[0] should not be present in layer tree at all. So, are you guys planning to fix this bug in the painting phase then (layer tree creation)? Let me know, if you want me to handle this in HwcComposer2D.

As in Comment 14, doing optimization in HwComposer is not ideal. This bug could be a bug to fix this problem. Right now, no one is assigned to this bug. If correct priority is assigned to this bug. Someone who know well around layout is going to handle this bug.

Milan, can we assign someone to this bug? This bug failed to become 1.4+. But we need to fix this problem. Can we set target to b2g-v2.1?

On one webgl game, there was 16% cpu usage difference between OpenGL composition and HwComposer composition. It show HwComposer composition could improve b2g performance. - OpenGL composition: 74 % cpu usage - HwComposer composition: 58% cpu usage I used "adb shell top -t -m 6" command to check it. More information is at Bug 1022823 Comment 25.

(In reply to Sotaro Ikeda [:sotaro] from comment #19) > On one webgl game, there was 16% cpu usage difference between OpenGL > composition and HwComposer composition. It show HwComposer composition could > improve b2g performance. > - OpenGL composition: 74 % cpu usage > - HwComposer composition: 58% cpu usage > > I used "adb shell top -t -m 6" command to check it. More information is at > Bug 1022823 Comment 25. Correction: The above is based on incorrect data. When HwComposer was used, FPS was dropped.

Assigning to :benwa, but I don't know how deep into layout we need to delve. :tn, can you assist or take over depending on what the answer to that ends up being?

To understand why we are getting a thebeslayer that is completely covered we need a display list dump. Can someone post one to this bug?

The problem seems to be coming from the parent process. The layers from the content process (where this display list dump looks like it is from) look good, just a canvas layer, and a thebeslayer with empty vis region, which should be ignored.

The remote iframe is contained in an opacity item with opacity 1, meaning there is either will-change or some animation on opacity on (some ancestor of) the remote iframe for the current app. This forces us to treat the foreground app as transparent.

(In reply to Timothy Nikkel (:tn) from comment #26) > The remote iframe is contained in an opacity item with opacity 1, meaning > there is either will-change or some animation on opacity on (some ancestor > of) the remote iframe for the current app. This forces us to treat the > foreground app as transparent. I landed bug 1024742 which will tell us if it's will-change. I strongly suspect then that is the case. Meanwhile bug 1024148 should simplify the system app along with a lot of pages.

Bug 1026240 seems to be responsible for all the extra layers we have received.

I just confirmed with sotaro' help, the problem is we're compositing over 150% of the screen area. We need to remove the overdraw coming from the app background. A quick look at the display list it should be optimized into a color layer but isn't.

Block graphic feature for FFOS 2.1 meta bug for tracking.

Note that this now blocks bug 1010638, which is currently marked as a 2.0 blocker. Sotaro, can you comment on this, specifically in terms of simplifying the layer tree that we need for that bug, and how much of this bug is related specifically to that.

This may be a simple fix, but I wouldn't count on there being a solution in the 2.0 timeframe, it depends on what ends up being an underlying issue.

Sorry, forgot to add needinfo...

(In reply to Jon Hylands [:jhylands] from comment #31) > Note that this now blocks bug 1010638, which is currently marked as a 2.0 > blocker. Sotaro, can you comment on this, specifically in terms of > simplifying the layer tree that we need for that bug, and how much of this > bug is related specifically to that. Sorry, BenWa is correct person to answer the question.

BenWa, can you answer the question?

I believe this can be fixed entirely in gaia. We need bug 1027231 fixed and I will verify bug 1026240 once I come back from vacation. Applying fixes locally with App manager to remove extra will-change and fix subpixel alignment I was able to get crystal skull to render with HWC on the flame.

bgirard - I appreciate the report, but I guess I wasn't very clear in what I was asking. I'm interested in this bug because we believe it might relate to bug 1010638, which appears to have power consumption issues caused by an overly complex layer tree. Is that the basic premise of what you're trying to fix here, or is that just one part of it?

Yes, the this bug is caused by a complex layer tree and they do look related. It will certainly help since all app on the Flame are getting a bad layer tree. But I can't say if it will be sufficient.

Per Benoit's comment 54 in bug 1010638, I'm changing this to a 2.0?

Back to 2.0? because of comment 8.

Keep in mind that the underlying issue we're tracking is that we can't efficiently handle a fullscreen webgl app. Crystal skull is just a trivial test case.

Keeping in mind comment #41 and keeping in mind that this blocks 1010638 and is a reduced testcase, blocking on this.

OK, let's clarify what we're tracking in this bug. We talk about Crystall Skull game in the summary, but it sounds like we want to track all WebGL apps in here. We are also talking about this blocking a bug that doesn't do any WebGL work, so are we using this bug for the fact that high overdraw stops us from using hardware composer? Which one is it?

(In reply to Milan Sreckovic [:milan] from comment #43) > so are we using this bug for the fact that high overdraw > stops us from using hardware composer? Yes, I am using this bug to track that high overdraw is preventing us from using HWC even in the most trivial cases. I've updated the description to reflect this.

This should be fixed on master now. b2g-2.0 is waiting for bug 1034347 to be uplifted.

We can now use HWC given that the app has an appropriate layer tree (like crystal skull).

Triage: Hey Benoit, can we close this now based on comment 46? Thanks!

Opps, meant to close.

Unable to verify the issue. This bug and dependencies do not have sufficient STRs and/or seem to be back end issues.