Closed Bug 1039927 Opened 10 years ago Closed 10 years ago

Inconsistent layer tree configuration

Categories

(Core :: Graphics, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
blocking-b2g 2.0+

People

(Reporter: bhargavg1, Assigned: milan)

References

Details

(Whiteboard: [CR 691001])

STR:
Start camcorder recording 
Start video playback(720p) full screen (landscape)
Start camcorder recording again. Now see that only 1 layer is being composed

==================
Video encode before starting the video decode
 
D/qdhwcomposer(  228): draw: MDP Comp not configured
E/HWComposer(  228): Frame rendered
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[0]::ColorLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=ff000000 Blendi=0x100 Flags=0x8
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[1]::ImageLayerComposite: dst=[0 1 480 800] src=[0.000000 24.000000 719.000000 456.000000] Tr=4 Blendi=0x100 Flags=0x0
E/HWComposer(  228): HWC layer[2]::ThebesLayerComposite: dst=[21 26 317 785] src=[0.000000 0.000000 296.000000 759.000000] Tr=0 Blendi=0x105 Flags=0x40
D/qdhwcomposer(  228): isFrameDoable: MDP Comp. not enabled.
D/qdhwcomposer(  228): prepare: MDP Comp not possible for this frame
D/qdhwcomposer(  228): GEOMETRY change: 0
D/qdhwcomposer(  228): HWC Map for Dpy: "PRIMARY" 
D/qdhwcomposer(  228): CURR_FRAME: layerCount: 3 mdpCount: 0 fbCount: 3 
D/qdhwcomposer(  228): needsFBRedraw:YES  pipesUsed: 0  MaxPipesPerMixer: 4 
D/qdhwcomposer(  228):  ---------------------------------------------  
D/qdhwcomposer(  228):  listIdx | cached? | mdpIndex | comptype  |  Z  
D/qdhwcomposer(  228):  ---------------------------------------------  
D/qdhwcomposer(  228):        0 |     YES |       -1 |      GLES | -1 
D/qdhwcomposer(  228):        1 |     YES |       -1 |      GLES | -1 
D/qdhwcomposer(  228):        2 |     YES |       -1 |      GLES | -1 
 
===================
Stop video encode and start video decode (720p full screen)
 
D/qdhwcomposer(  228): draw: MDP Comp not configured
E/HWComposer(  228): Frame rendered
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 800.000000 480.000000] Tr=7 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[0]::ColorLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 800.000000 480.000000] Tr=ff14120e Blendi=0x100 Flags=0x8
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 800.000000 480.000000] Tr=7 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[1]::ImageLayerComposite: dst=[15 1 465 800] src=[0.000000 0.000000 1280.000000 720.000000] Tr=7 Blendi=0x100 Flags=0x0
D/qdhwcomposer(  228): isFrameDoable: MDP Comp. not enabled.
D/qdhwcomposer(  228): prepare: MDP Comp not possible for this frame
D/qdhwcomposer(  228): GEOMETRY change: 0
D/qdhwcomposer(  228): HWC Map for Dpy: "PRIMARY" 
D/qdhwcomposer(  228): CURR_FRAME: layerCount: 2 mdpCount: 0 fbCount: 2 
D/qdhwcomposer(  228): needsFBRedraw:YES  pipesUsed: 0  MaxPipesPerMixer: 4 
D/qdhwcomposer(  228):  ---------------------------------------------  
D/qdhwcomposer(  228):  listIdx | cached? | mdpIndex | comptype  |  Z  
D/qdhwcomposer(  228):  ---------------------------------------------  
D/qdhwcomposer(  228):        0 |     YES |       -1 |      GLES | -1 
D/qdhwcomposer(  228):        1 |     YES |       -1 |      GLES | -1 
 
 
===========
 
after video decode start video encode. We see that now only one layer being composed 
 
D/qdhwcomposer(  228): draw: MDP Comp not configured
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[1]::ThebesLayerComposite: dst=[0 0 1 480] src=[0.000000 0.000000 1.000000 480.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): Color layer has semitransparency which is unsupported
E/HWComposer(  228): Render aborted. Nothing was drawn to the screen
D/qdhwcomposer(  228): isFrameDoable: MDP Comp. not enabled.
D/qdhwcomposer(  228): prepare: MDP Comp not possible for this frame
D/qdhwcomposer(  228): GEOMETRY change: 1
D/qdhwcomposer(  228): HWC Map for Dpy: "PRIMARY" 
D/qdhwcomposer(  228): CURR_FRAME: layerCount: 1 mdpCount: 0 fbCount: 1 
D/qdhwcomposer(  228): needsFBRedraw:YES  pipesUsed: 0  MaxPipesPerMixer: 4 
D/qdhwcomposer(  228):  ---------------------------------------------  
D/qdhwcomposer(  228):  listIdx | cached? | mdpIndex | comptype  |  Z  
D/qdhwcomposer(  228):  ---------------------------------------------  
D/qdhwcomposer(  228):        0 |     YES |       -1 |      GLES | -1 
D/qdhwcomposer(  228): 
D/qdhwcomposer(  228): draw: MDP Comp not configured
blocking-b2g: --- → 2.0?
We are seeing this inconsistency very often. As per Comment 0, when Camcorder recording is done 1st time, we see this layer tree:
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[0]::ColorLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=ff000000 Blendi=0x100 Flags=0x8
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[1]::ImageLayerComposite: dst=[0 1 480 800] src=[0.000000 24.000000 719.000000 456.000000] Tr=4 Blendi=0x100 Flags=0x0
E/HWComposer(  228): HWC layer[2]::ThebesLayerComposite: dst=[21 26 317 785] src=[0.000000 0.000000 296.000000 759.000000] Tr=0 Blendi=0x105 Flags=0x40

But after playing a video, when camcorder recording starts again, we see a different layer tree which does not take HWC Composition path, due to presence of an unsupported layer in frame:
E/HWComposer(  228): HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): HWC layer[1]::ThebesLayerComposite: dst=[0 0 1 480] src=[0.000000 0.000000 1.000000 480.000000] Tr=0 Blendi=0x100 Flags=0x40
E/HWComposer(  228): Color layer has semitransparency which is unsupported
E/HWComposer(  228): Render aborted. Nothing was drawn to the screen

Sotaro, this is a layer tree build-up issue. And I think it is due to some potential bug in layer tree build-up when the Camera App is moved to background and launched again. Who can take a look at this?

There is 1 more issue in this Bugzilla, if you see 1st configuration in Comment 0:
HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
HWC layer[1]::ImageLayerComposite: dst=[0 1 480 800] src=[0.000000 24.000000 719.000000 456.000000] Tr=4 Blendi=0x100 Flags=0x0
HWC layer[2]::ThebesLayerComposite: dst=[21 26 317 785] src=[0.000000 0.000000 296.000000 759.000000] Tr=0 Blendi=0x105 Flags=0x40

We could totally avoid Layer[0] from composition but Layer[1] is shifted by 1 pixel from top that's why we could not drop Layer[0]. I believe there was a Bugzilla bug for this, I don't remember. (A thin line at bottom in Youtube video playback frame). Do you remember it? And how to dump layer tree. The option in Settings does not work for me. I did adb reboot as well.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Sushil from comment #1)
> We could totally avoid Layer[0] from composition but Layer[1] is shifted by
> 1 pixel from top that's why we could not drop Layer[0]. I believe there was
> a Bugzilla bug for this, I don't remember. (A thin line at bottom in Youtube
> video playback frame). Do you remember it? And how to dump layer tree. The
> option in Settings does not work for me. I did adb reboot as well.

It is a layout level problem. BenWa or Matt knows well. 

BenWa, who is a correct person to investigate the problem?
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(bgirard)
The only thing I noticed is I don't get HWC when the focus icon is drawn on the screen. Is this what you're seeing?

To get a layers dump you need to:
$ ./edit-pref.sh
append:
user_pref("layers.dump", true);
Flags: needinfo?(bhargavg1)
Yes, I also do not see below error on latest v2.0 build during Camcorder recording. Bhargav, plz confirm.

E/HWComposer(  228): Color layer has semitransparency which is unsupported
E/HWComposer(  228): Render aborted. Nothing was drawn to the screen
So in this bug, we will debug the offset of 1 pixel on Image layer in Camcorder recording:

HWC layer[0]::ThebesLayerComposite: dst=[0 0 480 800] src=[0.000000 0.000000 480.000000 800.000000] Tr=0 Blendi=0x100 Flags=0x40
HWC layer[1]::ImageLayerComposite: dst=[0 1 480 800] src=[0.000000 24.000000 719.000000 456.000000] Tr=4 Blendi=0x100 Flags=0x0
HWC layer[2]::ThebesLayerComposite: dst=[21 26 317 785] src=[0.000000 0.000000 296.000000 759.000000] Tr=0 Blendi=0x105 Flags=0x40

We could totally avoid Layer[0] from composition but Layer[1] is shifted by 1 pixel from top that's why we cannot not drop Layer[0].
Component: Gaia::Camera → Graphics
Product: Firefox OS → Core
Do we know the app is not asking for this offset by 1?  Can somebody from the camera app actually verify that? If we're asking for it, we should stop.  If we're not asking for it, then the layout computing the layer origin off by 1 is the bug.
Flags: needinfo?(hkoka)
Flags: needinfo?(bugs)
Flags: needinfo?(bgirard)
A layer tree dump and a display list dump are good tools for figuring this out. Remember that CSS pixels != device pixels. We need to make sure that the app layout requests a whole number of device pixels whenever possible.
dmarcos/justin,

Can one of you please check per comment #6 and report back?

thanks
hema
Flags: needinfo?(jdarcangelo)
Flags: needinfo?(hkoka)
Flags: needinfo?(dmarcos)
(In reply to Milan Sreckovic [:milan] from comment #6)
> Do we know the app is not asking for this offset by 1?  Can somebody from
> the camera app actually verify that? If we're asking for it, we should stop.
> If we're not asking for it, then the layout computing the layer origin off
> by 1 is the bug.

What, specifically, are you asking about? It sounds like you're talking about a 1px offset of something in the Camera app, but I'm having difficulty following this bug.
Flags: needinfo?(milan)
For the Image Layer which has offset of 1 pixel from top, I noticed that it starts at http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcUtils.cpp#46 .

gfxRect visibleRectScreen = aTransform.TransformBounds(visibleRect);

I checked that visibleRect = [0 0 480 800] but aTransform.TransformBounds is transforming it to:
[0 0.75 480 799.25], which looks wrong and it should be leading to offset of 1. Can someone please check the transformation matrix of this layer which is passed from: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#299. For other layers in frame, aTransform.TransformBounds() result looks fine.
(In reply to Justin D'Arcangelo [:justindarc] from comment #9)
> ...
> What, specifically, are you asking about? It sounds like you're talking
> about a 1px offset of something in the Camera app, but I'm having difficulty
> following this bug.

Layer tree and display list dump would likely help a lot.
Flags: needinfo?(milan)
Ok, How do you get a layer tree and a display list? Sorry but we're not familiarized with your tooling.
Flags: needinfo?(dmarcos) → needinfo?(milan)
(In reply to Sushil from comment #10)
> For the Image Layer which has offset of 1 pixel from top, I noticed that it
> starts at
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcUtils.cpp#46 .
> 
> gfxRect visibleRectScreen = aTransform.TransformBounds(visibleRect);
> 
> I checked that visibleRect = [0 0 480 800] but aTransform.TransformBounds is
> transforming it to:
> [0 0.75 480 799.25], which looks wrong and it should be leading to offset of
> 1. Can someone please check the transformation matrix of this layer which is
> passed from:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.
> cpp#299. For other layers in frame, aTransform.TransformBounds() result
> looks fine.

The viewfinder <video> element in the Camera app has to be rotated and scaled to *fill* the screen using an aspect-fill algorithm. So basically, we select the preview size that is as close as possible to the screen dimensions and scale/center it so that there are no "black bars". In most cases, a preview size is available for us to use from the camera hardware that matches the screen size, so after applying our transform, the <video> element perfectly fills the entire screen. But in some cases, small portions of the video (either the top/bottom or left/right) are truncated off-screen so we ensure that the preview fills the entire area.

I'm not sure if that info helps at all, but as Diego mentioned, we're unfamiliar with the tools you are using.
Dump layers tree is a preference in the Settings menu. The display list requires a rebuild with 'export B2G_DUMP_PAINTING=1' in your .userconfig.

The display list is per process so it should be captured for both the system process and camera app while the problem is reproducing on the screen.
Flags: needinfo?(milan)
(In reply to Benoit Girard (:BenWa) from comment #3)
> The only thing I noticed is I don't get HWC when the focus icon is drawn on
> the screen. Is this what you're seeing?
> 

qdhwcomposer(  228): CURR_FRAME: layerCount: 2 mdpCount: 0 fbCount: 2 

the layerCount hasnt been consistent for me for the same usecase. Not able to re-produce this on the latest builds.
Flags: needinfo?(bhargavg1)
blocking-b2g: 2.0? → 2.0+
OK, let's pick this up once it can be reproduced.
Assignee: nobody → milan
Flags: needinfo?(bugs)
We still see offset of 1 pixel in Image layer in Camcorder recording, which I mentioned in Comment 5. But it should not add much to power consumption because we do not fetch all the hidden content of HWC layer[0] in this frame (given that HWC layer[1] has Opaque content). We have optimization in HWC HAL, so we just fetch 1 pixel line of visible src data of HWC layer[0]. So this bug is not so critical for 2.0 with respect to power consumption.
(In reply to Sushil from comment #17)
> We still see offset of 1 pixel in Image layer in Camcorder recording, which
> I mentioned in Comment 5. But it should not add much to power consumption
> because we do not fetch all the hidden content of HWC layer[0] in this frame
> (given that HWC layer[1] has Opaque content). We have optimization in HWC
> HAL, so we just fetch 1 pixel line of visible src data of HWC layer[0]. So
> this bug is not so critical for 2.0 with respect to power consumption.

Do you happen to know if that Image layer you're referring to is the <video> element?
Yes, it is the Video content layer (on Camcorder recording frame).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(jdarcangelo)
You need to log in before you can comment on or make changes to this bug.