827231 - Going to support.mozilla.org through the settings app and scrolling around - hard to scroll and it generates duplicated/smashed text

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, defect)

Description

[Jason Smith [:jsmith]]

Attachment: Smashed Dupe Text

Build: B2G 18 1/6/2013
Device: Unagi

Steps:

1. Go to settings --> improve firefox os --> learn more
2. Start scrolling around

Expected:

The text should be readable as you scroll around with no duplication or smashed text.

Actual:

See example screenshot. Smashed/duplicated text is being seen on the support site for the device.

Comment 1

[Andrew Overholt [:overholt]]

Milan, can you find someone to fix this?

Comment 2

[Jason Smith [:jsmith]]

I should note that the root cause here *might* be a scrolling problem that might be leading to the smashed text. If you scroll around on this site, it does dead stops while scrolling. If it turns out this is a different bug, then let me know and I'll file a separate one and nom it.

Comment 3

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

Vlad, I hear you're looking for a B2G gfx bug or two?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I can't scroll the support.mozilla.org site at all on either Unagi or Otoro.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)
> I can't scroll the support.mozilla.org site at all on either Unagi or Otoro.

I hit that problem as well, although pushing hard enough got it to scroll. Reworking title to the core of the problem (unless you think it's worthwhile to split this into two separate bugs).

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Roughly every 2nd scroll/pan operation seems to just be ignored.  There are actually all sorts of bugs with this site, both using the browser on FxOS and Firefox for Android.  The pannable content area is an absolute-positioned <div> with overflow: auto, but there's something rather weird about the site's CSS structure and layout that I can't replicate in a simplified testcase. (e.g. the header at the top acts as if its fixed, but everything is position: absolute as far as I can see).

(In reply to Jason Smith [:jsmith] from comment #5)
> Reworking title to the core of the problem (unless you think it's worthwhile
> to split this into two separate bugs).

I don't think you can rework something to the 'core' of the problem by turning it into two problems where there was one mentioned before :)

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Once the duplication happens, if you pan up/down slowly it will usually show up/hide when you cross a particular threshold.  Turning on paint flashing shows that when the duplicate bits are present, their paint flash "pattern" is always the same -- that is, it's old data from some other buffer that's being painted, rather than the text being painted again.  It generally appears in the spaces between text paragraphs, but it doesn't slide into place as I'd expect if it was just an old buffer being painted underneath or something -- it becomes fully visible/hidden as you cross whatever the threshold is.

Comment 8

[JP Rosevear [:jpr]]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #6)
> Roughly every 2nd scroll/pan operation seems to just be ignored. 

This bit sounds a lot like bug 827715.

Comment 9

[Jason Smith [:jsmith]]

(In reply to JP Rosevear [:jpr] from comment #8)
> (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #6)
> > Roughly every 2nd scroll/pan operation seems to just be ignored. 
> 
> This bit sounds a lot like bug 827715.

Should we link these two bugs up (this one is dependent on bug 827715)? Or do we definitely know this is a dupe?

Chris - Do you know? Dupe, dependency?

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Probably related but let's stay focused on the rendering glitch here.

Comment 11

[Matt Woodrow (:mattwoodrow)]

I think this bug is fixed by the latest patch in bug 818575.

I wasn't able to reproduce the exact issue that was reported, but I did see similar incorrect painting/broken scrolling issues that are fixed.

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #11)
> I think this bug is fixed by the latest patch in bug 818575.
> 
> I wasn't able to reproduce the exact issue that was reported, but I did see
> similar incorrect painting/broken scrolling issues that are fixed.

Bug 818575 does not fix this bug, unfortunately -- just tested.

This is looking like an issue with buffer rotation, or at least with repainting these layers.  The layer that we create for the content here is pretty complex; its background seems to be transparent and we have a complex valid region.  I think that what's happening is that as we scroll, those regions are getting out of sync with reality and we end up rendering to or from "old" areas of the texture.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: good and bad frames

So here's two subsequent frames where the badness happens.  The frame on the left is the first "good" frame, and then on the right is the "bad" frame.

Good (Left): @(4d2f0425a214c)                 OGLShadowThebesLayer (0x43edc090) [shadow-transform=[ 1 0; 0 1; 0 -3527; ]] [shadow-visible=< (x=15, y=3589, w=290, h=303); >] [transform=[ 1 0; 0 1; 0 -3527; ]] [visible=< (x=15, y=3589, w=290, h=303); >] [opaqueContent] [valid=< (x=15, y=3589, w=320, h=314); >]

Bad (Right): @(4d2f0425e255c)                 OGLShadowThebesLayer (0x43edc090) [shadow-transform=[ 1 0; 0 1; 0 -3569; ]] [shadow-visible=< (x=15, y=3622, w=290, h=298); (x=15, y=3920, w=274, h=14); (x=289, y=3920, w=16, h=3); >] [transform=[ 1 0; 0 1; 0 -3569; ]] [visible=< (x=15, y=3622, w=290, h=298); (x=15, y=3920, w=274, h=14); (x=289, y=3920, w=16, h=3); >] [opaqueContent] [valid=< (x=15, y=3622, w=320, h=314); >]

Comment 14

[Matt Woodrow (:mattwoodrow)]

I can't reproduce this on the emulator (OSX, omtc/multi process all enabled), so figuring out what relevant code paths are different between the two configurations might be useful.

We're at least using pixman on the device, and not on desktop. Not sure what the differences in the layers configuration are.

Comment 15

[Doug Turner (:dougt)]

Moving to tef+/tracking. *please* continue working on this as it is very important that we do fix this bug.

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: bug image

Ok, this looks like what's going on.  This layer is marked as [contentOpaque] in layers dumping, though as can be seen, it still has transparent regions (with some really odd ones, like the thin horizontal transparent bits).  In the left "good" frame, there's a transparent region at the bottom of the texture.

Sometime between going from the left frame to the right (there have been a few frames lost in between here due to the perf overhead of my texture dumping code), we blitted the content in the left frame upwards.  When we did this, we blitted the transparent region over top of where the existing text was -- and didn't render anything over it, so it was a no-op.  Then we rendered the "Firefox for Android." on the left, making that look correct, and at some point rendered the white background on the bottom.

That's where the corruption is coming from; we have transparent regions in a layer marked as opaque, and were doing blitting upwards and not re-rendering everything that we should be.

Trying to figure out what's causing this; but it could be a few different things:

1) RGBA texture being created for the layer, with the layer thinking that it's opaque -- the A byte will have basically random things from Thebes rendering;
2) incorrect setting of the opaque flag;
3) ... something else.

I'm guessing it's not 2 -- the opaque flag looks correct for this layer.  So I'm thinking it's #1, and given that this is a thebes layer that's coming from the browser, then it'll be a shared gralloc texture image -- which is why it's only being seen on a physical b2g device (though if we're doing a hardware emulator with the full gonk layer, it should be seen there as well...)

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Keep in mind that the "opaque" flag means that the *visible region* is opaque. If the visible region is not rectangular --- or otherwise doesn't fill the texture --- we could quite validly have transparent pixels in the texture outside the visible region. (This doesn't contradict anything you said, but it's easy to get confused about.) Anyway it'd be worth checking whether all the pixels in the visible region are opaque in your case.

Comment 18

[Jason Smith [:jsmith]]

Can someone provide the rationale why this was minused?

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'm heading on vacation tomorrow (back on the 28th); I'll likely keep poking at this, but if someone wants to grab it away from me in the meantime, they're welcome to.  Current theory is that the complicated front/back buffer swap machinery is getting the valid region confused (especially when scrolling/unrotation are involved).

I attempted to force a new buffer being created by always going through the resize path in ThebesLayerOGL Swap (where we destroy the current front buffer).  However, that resulted in lots of black squares being rendered, which definitely doesn't seem like the right outcome!

Comment 20

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I also don't agree with this being minused -- it seems like a minor issue, but it could be masking a much bigger problem that could bite us elsewhere.

Comment 21

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

Is this still a problem?

Comment 22

[Verdi [:verdi] Best to slack me]

This seems to have been fixed a while ago. Browsing the support site works nicely.

Comment 23

[Natalya Kot [:nkot]]

have also tested it,
- browsing support.mozilla.org works nicely, easy to scroll, no duplicated/smashed text is generated 

Leo  (v1.1, build ID:20130910041240)
Buri (v1.2, build ID:20130911040201)