923681 - Summit app draw problems - needs sleep to refresh

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Not what it's supposed to look like.

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.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

BenWa, does the buffer un-rotate fix this?

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Hmm, this could be invalidation instead?

Comment 4

[Gregor Wagner [:gwagner]]

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.

Comment 5

[Lucas Adamski [:ladamski]]

I tried it again and it reproed pretty quickly (peak, 1.2 build id 20131010205456)

Comment 6

[Lucas Adamski [:ladamski]]

Gregor, is that a leo 1.1 build?  The new graphics stuff is only in 1.2+.

Comment 7

[Gregor Wagner [:gwagner]]

(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.

Comment 8

[Nicolas Silva [:nical]]

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)

Comment 9

[Nicolas Silva [:nical]]

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?

Comment 10

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 11

[Nicolas Silva [:nical]]

This video illustrates the misplaced layer problem I mentioned in comment 8

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

Comment 12

[Nicolas Silva [:nical]]

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

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

I can see still it on Unagi with the latest 1.2 build.

Comment 14

[Nicolas Silva [:nical]]

Actually I can reproduce the bug again now, except for moving around the container layers.

Comment 15

[Nicolas Silva [:nical]]

(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).

Comment 16

[Kartikaya Gupta (email:[e-mail])]

(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)

Comment 17

[Nicolas Silva [:nical]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 18

[Nicolas Silva [:nical]]

Fixed by BenWa's patch in bug 921212.