Closed
Bug 1039927
Opened 10 years ago
Closed 10 years ago
Inconsistent layer tree configuration
Categories
(Core :: Graphics, defect)
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
Blocks: CAF-v2.0-FC-metabug
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)
Comment 2•10 years ago
|
||
(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)
Comment 3•10 years ago
|
||
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].
Updated•10 years ago
|
Component: Gaia::Camera → Graphics
Product: Firefox OS → Core
Assignee | ||
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
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)
Comment 9•10 years ago
|
||
(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)
Comment 10•10 years ago
|
||
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.
Assignee | ||
Comment 11•10 years ago
|
||
(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)
Comment 12•10 years ago
|
||
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)
Comment 13•10 years ago
|
||
(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.
Comment 14•10 years ago
|
||
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)
Reporter | ||
Comment 15•10 years ago
|
||
(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)
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Assignee | ||
Comment 16•10 years ago
|
||
OK, let's pick this up once it can be reproduced.
Assignee: nobody → milan
Flags: needinfo?(bugs)
Comment 17•10 years ago
|
||
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.
Comment 18•10 years ago
|
||
(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?
Comment 19•10 years ago
|
||
Yes, it is the Video content layer (on Camcorder recording frame).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Updated•10 years ago
|
Flags: needinfo?(jdarcangelo)
You need to log in
before you can comment on or make changes to this bug.
Description
•