Closed Bug 923681 Opened 6 years ago Closed 6 years ago

Summit app draw problems - needs sleep to refresh

Categories

(Core :: Graphics, defect)

26 Branch
x86
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla27
blocking-b2g koi+
Tracking Status
firefox25 --- wontfix
firefox26 --- fixed
firefox27 --- fixed
b2g-v1.2 --- fixed

People

(Reporter: milan, Assigned: nical)

References

Details

Attachments

(1 file)

Tested on unagi with 1.2.  Not sure if this is graphics or layout.

1. Go to summit.mozilla.org, Friday, Toronto.
2. Try scrolling to the bottom.

Problem: Rendering problems, different items appearing on top of each other (see attached)

Turning the screen off and back on fixed this, so I'm thinking graphics.
BenWa, does the buffer un-rotate fix this?
Assignee: nobody → bgirard
blocking-b2g: --- → koi?
Hmm, this could be invalidation instead?
Summary: Summit up draw problems - needs sleep to refresh → Summit app draw problems - needs sleep to refresh
Duplicate of this bug: 923954
Blocks: GFXB2G1.2
blocking-b2g: koi? → koi+
Lucas showed me the bug in Brussels and I tried with todays leo build from mwu and I can't reproduce it on my leo device.
Same app, same page.
I tried it again and it reproed pretty quickly (peak, 1.2 build id 20131010205456)
Gregor, is that a leo 1.1 build?  The new graphics stuff is only in 1.2+.
Flags: needinfo?(anygregor)
(In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #6)
> Gregor, is that a leo 1.1 build?  The new graphics stuff is only in 1.2+.

Oh yes that was the official 1.1 build. sorry for the spam.
Flags: needinfo?(anygregor)
Assignee: bgirard → nical.bugzilla
Looking at the page with flash painting + layer borders shows that the problems comes from misplaced layers (that is merged back in a bigger layer after scrolling stops)
This is a really fun bug! This video shows that we can also move some container layers (along with their children) around.

https://dl.dropboxusercontent.com/u/7742672/summit-app-bug-01.mp4

APZC going wild?
Flags: needinfo?(bugmail.mozilla)
That *is* pretty wild. I see the bajillions of layers on my Hamachi running 1.2 but not on the Peak running master. On neither of them can I drag around the layers like you did though. Looking at the source for the page it does look like the <p class="city-stats"> container element has overflow:auto, so in theory it could become scrollable. However for the layer to end up scrollable like that the FrameMetrics must be really messed up.

nical, can you dump the frame metrics for the container layer that you were dragging around? If there's something wrong there it should be evident, and would point to a bug on the layout side of things. If it looks sane then it's a bug on the APZC side of things.
Flags: needinfo?(bugmail.mozilla)
This video illustrates the misplaced layer problem I mentioned in comment 8

https://dl.dropboxusercontent.com/u/7742672/summit-app-bug-02.mp4
disappointingly, I was testing on a somewhat old build and after I updated I haven't been able to reproduce the problems described in this bug.

The frame metrics for the thin container layers have the following values:
may have touch listener: 0
scrollablde: 1
scroll offset: 0.000000 0.500000
scrollable rect x:0.000000 y:0.000000 w:227.000000 h:16.500000
I can see still it on Unagi with the latest 1.2 build.
Actually I can reproduce the bug again now, except for moving around the container layers.
(In reply to Nicolas Silva [:nical] from comment #8)
> Looking at the page with flash painting + layer borders shows that the
> problems comes from misplaced layers (that is merged back in a bigger layer
> after scrolling stops)

After Comparing the page rendered on several devices at the same time, I think it is not the layer that is misplaced, but the content behind it that is painted incorrectly. The layer feels out of place but it actually is where it should be whereas the painted stuff behind it is bad until reflow happens (for example when expanding the item).
(In reply to Nicolas Silva [:nical] from comment #12)
> The frame metrics for the thin container layers have the following values:
> may have touch listener: 0
> scrollablde: 1
> scroll offset: 0.000000 0.500000
> scrollable rect x:0.000000 y:0.000000 w:227.000000 h:16.500000

I'd like to see all of the values in the FrameMetrics if you can get them. I recently added a APZC_LOG_FM macro at [1] that you can copy to dump stuff out. From the stuff above though it looks like maybe the layer is scrollable by 0.5 pixels which is a little weird.

> (In reply to Nicolas Silva [:nical] from comment #8)
> After Comparing the page rendered on several devices at the same time, I
> think it is not the layer that is misplaced, but the content behind it that
> is painted incorrectly. The layer feels out of place but it actually is
> where it should be whereas the painted stuff behind it is bad until reflow
> happens (for example when expanding the item).

I'm not entirely sure what this means. Do you mean that when you were "dragging" the layer (video in comment 9) entire page was moving but the stuff behind was not updating correctly?

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#57(In reply to Nicolas Silva [:nical] from comment #15)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #16)
> I'm not entirely sure what this means. Do you mean that when you were
> "dragging" the layer (video in comment 9) entire page was moving but the
> stuff behind was not updating correctly?

No, there are two problems in this bug, the original one (see Milan's attachement) is that thebes layers are painted incorrectly. The second one, was being able to drag the container layers, but I could only reproduce on a few weeks old build. I can't reproduce this problem anymore.

What I am referring to in comment 15 is the first problem. Which still reproduces on mozilla-central.

However, I have been testing this a lot with BenWa's unrotate patch, and it seems to have fixed the bug.
Fixed by BenWa's patch in bug 921212.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Depends on: 921212
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.