pedrogfrancisco Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.13 Safari/537.36

Steps to reproduce:

Go to http://www.wired.com/2014/10/google-chrome-helper/
Wait loading to finish
Wait 5s


Actual results:

Text gets blurry for 0,5s


Expected results:

Text should keep sharp

	pedrogfrancisco Reporter
	Comment 1 • 10 years ago

Cyanogen 11M11 but I think it also happened on Android 4.3.

If you wish I can revert to AOSP4.3 to test.

	Aaron Train [:aaronmt]
	Comment 3 • 10 years ago

If what you're seeing resolves itself after the page is done loading then this is expected.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 4 • 10 years ago

I saw this the other day as well. This didn't look like anything I've seen before, and it didn't look right. No idea what's causing it though. I saw it twice but I can't recall if both instances were on wired.com. At least one of them was.

	pedrogfrancisco Reporter
	Comment 5 • 10 years ago

It happens on a finished loaded page.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 6 • 10 years ago

I can reproduce this on current release and aurora channels, but not on beta and nightly. Weird, maybe it's an intermittent thing, and I'm only hitting it sometimes.

Also this page has some obvious script errors because when you load it you can see some script snippet at the top in plaintext.

	markrian
	Comment 7 • 10 years ago

I can confirm the original report on this bug.

Interestingly, a different page I found on wired.com, http://www.wired.com/2014/10/astrophysics-interstellar-black-hole/?mbid=social_twitter, has slightly different behaviour: the blurriness of the text isn't a function of time, but more a function of scroll position (and afaict, the page has finished loading). Scrolling from any direction reproduces the blurriness at those scroll points. I'll attach some screenshots.

	Kevin Brosnan [Ex-Mozilla]
	Comment 11 • 10 years ago

I saw this on Forbes.com too.

	James Willcox (:snorp) (jwillcox@mozilla.com) (he/him)
	Comment 12 • 10 years ago

(In reply to Kevin Brosnan [:kbrosnan] from comment #11)
> I saw this on Forbes.com too.

I've also seen it on forbes, though it doesn't seem to be consistent.

	u279076
	Comment 13 • 10 years ago

I'm able to reproduce this quite frequently on wired.com articles with my Moto G 2nd Gen phone running Android 4.4.4. I can reproduce in Fennec 35.0a2 and 36.0a1 but not Chrome.

	James Willcox (:snorp) (jwillcox@mozilla.com) (he/him)
	Comment 14 • 10 years ago

Milan, can we get someone to look at this?

	Milan Sreckovic [:milan] (needinfo for best results) Assignee
	Comment 15 • 10 years ago

Can we get a regression range?

	u279076
	Comment 16 • 10 years ago

Ioana, can your team track down a regression window for this bug?

	Catalin Suciu [:csuciu]
	Comment 17 • 10 years ago

good build: 15-07-2014
bad build: 16-07-2014

pushlog:http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=095d2a9c2be5&tochange=869971ad9fd6

	James Willcox (:snorp) (jwillcox@mozilla.com) (he/him)
	Comment 18 • 10 years ago

(In reply to Catalin Suciu from comment #17)
> good build: 15-07-2014
> bad build: 16-07-2014
> 
> pushlog:http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=095d2a9c2be5&tochange=869971ad9fd6

Quite a bit of stuff in there. Can we get a narrowed range?

	:garvan
	Comment 19 • 10 years ago

I just ran into this bug, couldn't repro, found this bugzilla bug, and can repro reliably with the page from comment 1

Video of behaviour (download video for full-res.):
https://drive.google.com/file/d/0B1sYPwjczMsQdFUwdGdhTk1FQUk/view?usp=sharing
Page is fully loaded. Video shows page stops text fuzz-no-fuzz loop after scrolling to the top (after page is scrolled to top in video, bug no longer happens).

Aurora 36.0a2 (01-12)
Nexus 5
Android 5.0.1

	:garvan
	Comment 20 • 10 years ago

Just clear the ni when you see this.

Here is the log: https://drive.google.com/file/d/0B1sYPwjczMsQTjFpeEpGdXJjc28/view?usp=sharing

This was exactly this bug, fuzzing on a 5sec cycle, for 0.5 sec. No other page is shown in the log, no other activity in fennec. You can see the logs starts with an install of your fennec logging build, then I immediately boot fennec, load:
https://drive.google.com/file/d/0B1sYPwjczMsQTjFpeEpGdXJjc28/view?usp=sharing

And after page loading is complete, it begins the fuzz cycle. I scrolled down on the page, fuzz continues. I left the page up for a minute or longer. And stopped the logging at that point.

	:garvan
	Comment 21 • 10 years ago

Correction to comment 20, I pasted the same link twice, the second link should be:
http://www.theglobeandmail.com/report-on-business/top-business-stories/canadian-dollar-sinks-ever-deeper-there-will-be-consequences/article22696124/

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 22 • 10 years ago

Thanks for the log! Unfortunately, I must have misunderstood, I thought the bug you were seeing was something like bug 1127485. This one, with blurriness coming and going, is not related to tiling and so the tiling logging won't help here. :(

If you do see something like bug 1127485 (see the screenshot on that bug for what it looks like) then a tiling long would be helpful.

	James Willcox (:snorp) (jwillcox@mozilla.com) (he/him)
	Comment 23 • 10 years ago

Kats how is this not tiling related? It's pretty clearly painting the low-res tiles instead of the high-res ones.

The following pattern is constantly repeated in the log:

I/Gecko   ( 4479): TILING 0x8e70f000: Initial visible region < (x=0, y=0, w=1080, h=10624); >
I/Gecko   ( 4479): TILING 0x8e70f000: Initial valid region < (x=0, y=0, w=1080, h=4097); >
I/Gecko   ( 4479): TILING 0x8e70f000: Initial low-precision valid region < >
I/Gecko   ( 4479): TILING 0x8e70f000: Found scrollAncestor 0x8e699f80 and displayPortAncestor 0x8e699f80
I/Gecko   ( 4479): TILING 0x8e70f000: Critical displayport (x=0, y=0, w=1080, h=4097)
I/Gecko   ( 4479): TILING 0x8e70f000: Resolution 2.997995
I/Gecko   ( 4479): TILING 0x8e70f000: Composition bounds (x=0.000000, y=0.000000, w=1080.000000, h=1843.766846)
I/Gecko   ( 4479): TILING 0x8e70f000: Scroll offset (0,0)
I/Gecko   ( 4479): TILING 0x8e70f000: First-transaction valid region < (x=0, y=0, w=1080, h=4097); >
I/Gecko   ( 4479): TILING 0x8e70f000: First-transaction invalid region < >
I/Gecko   ( 4479): TILING 0x8e70f000: Low-precision invalid region < (x=0, y=4097, w=1080, h=6527); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive paint: low-precision invalid region is < (x=0, y=4097, w=1080, h=6527); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive paint: low-precision old valid region is < (x=0, y=4096, w=1080, h=6528); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update valid region < >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update invalid region < (x=0, y=4097, w=1080, h=6527); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update old valid region < (x=0, y=4096, w=1080, h=6528); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update stale region < (x=0, y=4097, w=1080, h=6527); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update view transform (0,0) zoom 1.000000 abort 1
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update computed paint region < > repeat 0
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update final valid region < > buffer changed 0
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive update final invalid region < (x=0, y=4097, w=1080, h=6527); >
I/Gecko   ( 4479): TILING 0x8e70f000: Progressive paint: low-precision new valid region is < >
I/Gecko   ( 4479): TILING 0x8e70f000: Paint finished

The "view transform" one is especially interesting as it seems to indicate that it's going to abort the high-precision paint. That '1' is the abortPaint value, which is computed by some stuff here[0]. One of the things it seems to do is ask if the invalid region is contained in the stale region
, and you can see those are suspiciously off by one. Smells like some sort of rounding issue, but I don't really understand this code, as you can tell.

[0] https://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/TiledContentClient.cpp?from=TiledContentClient.cpp#1387

	:garvan
	Comment 24 • 10 years ago

The bug I was referring to on IRC today was bug 1115434

However when I tried to repro, with the same web page, I started getting this bug instead. I don't get both, I either get this bug happening or 1115434. I can't predict which bug will happen (not yet anyway), but usually one of the 2 will occur after a few tries.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 25 • 10 years ago

@snorp: the thing that is being aborted in the log snippet you posted is the low-precision paint, not the high precision paint. The high precision area is fully valid already. Also note that low-precision content is drawn at 50% opacity, which is not the case in the screenshot.

I also just went to the globe and mail website linked in comment 21 and I was able to see the fuzzy text. It seems to be specific to zoom levels; if i zoom in as far as i can it appears sharp but zooming out to the initial view makes it look bad. It seems to be that at certain resolutions the font being used just doesn't rasterize cleanly and pixellates. I haven't seen it cycle on and off but that might be a separate bug.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 26 • 10 years ago

Cc'ing :jfkthame who might be able to provide some insight into the text rasterization aspect of this. If I can still reproduce it tomorrow I can try to make a video demonstrating what I see.

	:garvan
	Comment 27 • 10 years ago

My bug is not text related, notice that the graphics also fuzz out (the Buick Ad):
https://drive.google.com/file/d/0B1sYPwjczMsQZGU5TEtySlF3MG8/view?usp=sharing

	:garvan
	Comment 28 • 10 years ago

At the 14sec mark, the graphic is fuzzy (look at the spokes on the car wheel for example), at 15 sec, it is clear again. (Sorry, I only showed the graphic briefly in my vid)

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 29 • 10 years ago

I can't really make out the car wheel spokes in the video, but I reloaded the page a few times and did end up getting a plain image ad - and you're right, it was blurry too. In that case it's not likely to be text rasterization but maybe compositor scaling? Maybe we're not rendering at the right resolution? I put a video at people.mozilla.org/~kgupta/bug/1085076.3gp which shows how the zoom level affects the bluriness of the text - this is definitely not a result of low-res tiling.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 31 • 9 years ago

I've seen this issue intermittently and was able to reproduce on my Nexus 5 Android 5.1 Fennec 40.0a1 (2015-03-31) consistently today on theatlantic.com.

http://m.theatlantic.com/international/archive/2015/03/the-hidden-consequences-of-low-oil-prices/389156/