Timothy Nikkel (:tnikkel) Reporter
	Description • 9 years ago

Load http://www.winnipegfreepress.com/arts-and-life/entertainment/TV/hockey-wives-stickhandle-lives-and-work-off-the-ice-296530101.html?device=mobile scroll. The text will alternately look fine, bad, and worse, and then fine again. What's weird is that other articles on the same site do not have this problem. I tested in Firefox Beta latest as of today.

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

There's a slew of bugs like these on file; see bugzil.la/whiteboard:layer-tiles

If you can consistently reproduce on nightly it would be good to investigate as we've had trouble finding reproducible scenarios and it's a high visibility issue.

	Timothy Nikkel (:tnikkel) Reporter
	Comment 2 • 9 years ago

Yes, consistently reproduces for me on nightly. mstange said he could reproduce too.

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

In that case please investigate, it would be good to at least figure out what's causing it even if the fix turns out to be nontrivial.

	Timothy Nikkel (:tnikkel) Reporter
	Comment 4 • 9 years ago

So it appears as though when we draw the text blurry we decide to render a transform that contains the test as active, when the transform is rendered as inactive the text looks fine. Dissecting the page on desktop the transform seems to be a translate only, and it doesn't seem to be changing at all. So not sure why it becomes active and then inactive and the active again. Also odd is that the layer dump for the active transform case has a prescale of 1,4 (scalex=1, scaley=4). I dont see any transform on the page at all with a scale, nevermind unequal x and y scales.

	Timothy Nikkel (:tnikkel) Reporter
	Comment 5 • 9 years ago

It looks like when choosing the scale in FrameLayerBuilder we are exceeding the max texture size so the code in RestrictScaleToMaxLayerSize shrinks our value to be under the max texture size and then scales us up by that factor.

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

We should be able to just ignore the max texture size if tiling is enabled, I think.

	Timothy Nikkel (:tnikkel) Reporter
	Comment 7 • 9 years ago

I think we have to make sure that the layer in question will be tiled too.

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

The root cause behind this bug (and all the dupes) is somewhat described in bug 1159564 comment 11. Copying it here:

This has something to do with wrapping preserve-3d transforms, I think. When I traced through the code, after starting the video the childrenVisible rect at [1] becomes ginormous, causing the aVisibleRect passed to ChooseScaleAndSetTransform to also become ginormous. This exceeds the max layer size and then causes the pre-scale to be applied.

Tracing backwards from there, the big childrenVisible rect was coming from an nsDisplayTransform which was coming from [2]. It looks like to me that |aTemp| there collects a lot of items before it finally gets flushed, and so the nsDisplayTransform that holds all of those items has a super-tall childrenVisible rect. I stuck in the attached wonderful hack which seemed to fix the problem, confirming my diagnosis. I don't know enough about this code to know if this is the root-cause or not, though. From a cursory reading of this code it doesn't like it would be a problem to split one nsDisplayTransform into a bunch but I don't really know. Somebody who knows the preserve-3d code should look into this.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/FrameLayerBuilder.cpp?rev=9da538675a2d#4755
[2] http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp?rev=9da538675a2d#1799

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

Here's the patch that I posted on bug 1159564 (not landable at all). Matt, do you have any suggestions on how to fix this, since you probably know more about this preserve-3d stuff?

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

I don't think tn is actively working on this either, so unassigning.

	Matt Woodrow (:mattwoodrow)
	Comment 18 • 9 years ago

Bug 1097464 is going to remove WrapPreserve3DList entirely, so that will hopefully fix this issue (or move it to a different location).

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

This is showing up on B2G (bug 1203971) as well as desktop (bug 1203109) - both of those are on medium.com articles. Moving this to layout and making it cross-platform.

	Markus Stange [:mstange] Assignee
	Comment 23 • 9 years ago

Bug 1144534 - If we have tiling, don't reduce layer resolution for large transforms. r?mattwoodrow

With bug 1207590 we can be sure that large PaintedLayers will be tiled whenever
tiling is available. Large intermediate surfaces might still be a problem, but
those should be required much less often once we have bug 1021845.

	Matt Woodrow (:mattwoodrow)
	Comment 24 • 9 years ago

Comment on attachment 8664862 [details]
MozReview Request: Bug 1144534 - If we have tiling, don't reduce layer resolution for large transforms. r?mattwoodrow

https://reviewboard.mozilla.org/r/20043/#review18063

	Pulsebot
	Comment 25 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/99f8738f9169

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 26 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/99f8738f9169