Closed Bug 808491 Opened 12 years ago Closed 12 years ago

CSS3 transform is incorrect when disable HWA

Categories

(Core :: Graphics: Layers, defect)

18 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19
Tracking Status
firefox18 + verified
firefox19 + fixed

People

(Reporter: alice0775, Assigned: mattwoodrow)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image screen shot
Build Identifier:
http://hg.mozilla.org/releases/mozilla-aurora/rev/e070197f4c89
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121104042011

This is similar to Bug 808486, but it is different regression range.

Steps to reproduce:
1. Disable HWA and restart browser.
2. Open http://desandro.github.com/3dtransforms/examples/carousel-01.html

Actual results:
CSS3 transform is incorrect

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/80499f04e875
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120918235157
Bad:
http://hg.mozilla.org/mozilla-central/rev/0c8ac138706e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120919071856
Pushlog;
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80499f04e875&tochange=0c8ac138706e


Regression window(m-c)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/176b61afc41d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120917231201
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/be9f5e549658
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120918023502
Pushlog;
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=176b61afc41d&tochange=be9f5e549658

Suspected; Bug 777194

Graphics
Adapter Description : ATI Radeon HD 4300/4500 Series
Adapter Drivers : aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM : 512
ClearType Parameters : Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 50
Device ID : 0x954f
Direct2D Enabled : no information
DirectWrite Enabled : false (6.1.7601.17789)
Driver Date : 7-3-2012
Driver Version : 8.970.100.3000
GPU #2 Active : false
GPU Accelerated Windows : 0/1 Basic no information
Vendor ID : 0x1002
WebGL Renderer : Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series)
AzureCanvasBackend : cairo
AzureContentBackend : none
AzureFallbackCanvasBackend : none
Tracking for 18 and passing on to roc, as this is a suspected regression from Bug 777194
Assignee: nobody → roc
This looks like another overflow area issue.
I think I should give CSS 3D transform overflow-area bugs to Matt :-)
Assignee: roc → matt.woodrow
How is this different to bug 808486, it's the same URL and looks like the same incorrect drawing. I don't see how these can have different regression ranges.

Anyway the problem here (for both bugs) is that we're detecting that the transformed layers have text over transparent and marking them as needing component alpha.

We flatten the layers, which means that sorting no longer works, and we still don't get subpixel AA on the text because it's not supported with 3d transforms. :(
This fixes the bug for me.

I don't really understand the regression range though, on either bug. Seems much more likely to have been caused by bug 741682.
Attachment #679027 - Flags: review?(roc)
Comment on attachment 679027 [details] [diff] [review]
Force 3d transformed layers to be active

Review of attachment 679027 [details] [diff] [review]:
-----------------------------------------------------------------

The code here is OK. But can we just turn off subpixel AA for 3D-transformed layers? I don't think subpixel AA makes sense for them anyway!
How would that work?

We don't actually draw them with component alpha regardless of platform, since they get a temporary transparent surface, and we can't copy the background up.

I guess we could try and block the propagation of Layer::SURFACE_COMPONENT_ALPHA through ContainerLayers if it won't actually be used.

It would be nice to be able to query SupportsComponentAlphaChildren(), but this isn't computed until draw time. I guess we could just duplicate some of the logic and explicitly check for 3d transforms?
ContainerParameters::mDisableSubpixelAntialiasingInDescendants already tries to do this. It disables subpixel AA in any active 3D transforms. I think it needs to disable subpixel AA for inactive 3D transforms as well. Does that fix the bug?

BTW, currently FrameLayerBuilder's SuppressComponentAlpha scans up the frame tree (but not across documents) looking for transformed ancestors. That's kinda bogus and I think redundant with mDisableSubpixelAntialiasingInDescendants and should probably be removed.
Unfortunately not, one of the panes is always perpendicular to the screen and returns true for CanDraw2D.

That makes the ContainerLayer for that pane have SURFACE_COMPONENT_ALPHA, and we then trigger flattening for the whole lot.

ContainerLayerOGL at least is using Is2D instead of CanDraw2D for determining if it can copy the background up, so switching to that would fix this test case at least.


I still feel like the underlying issue isn't solved, and that's that we don't ever want 3d transformed layers to be flattened.

We could re-break this testcase by adding another component alpha layer that isn't 3d transformed. That would still trigger flattening on the parent container, and cause all the 3d transfoms to be flattened too.
(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> I still feel like the underlying issue isn't solved, and that's that we
> don't ever want 3d transformed layers to be flattened.
> 
> We could re-break this testcase by adding another component alpha layer that
> isn't 3d transformed. That would still trigger flattening on the parent
> container, and cause all the 3d transfoms to be flattened too.

Right. Let's take your first patch to fix that, and also take a patch to turn off subpixel AA in 3D-transformed layers (that's just going to look bad).
https://hg.mozilla.org/mozilla-central/rev/2e813df0aca1
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
FYI
The problem of attachment 678183 [details] ( Bug 807563 Comment 7) is still exist in Nightly19.0a1.
OS: Windows 7 → All
Comment on attachment 679027 [details] [diff] [review]
Force 3d transformed layers to be active

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 741682
User impact if declined: Broken 3d transform sorting on BasicLayers
Testing completed (on m-c, etc.): Been on m-c for a few days
Risk to taking this patch (and alternatives if risky): Should be fairly low risk.
String or UUID changes made by this patch: None
Attachment #679027 - Flags: approval-mozilla-aurora?
Comment on attachment 679027 [details] [diff] [review]
Force 3d transformed layers to be active

[Triage Comment]
FF18 regression - let's get this ironed out even if there aren't any known regressions on major web properties. We're far enough from release that non-zero risk won't be a problem.

If this is landed on mozilla-aurora before ~11AM PT tomorrow, this will make the merge from Aurora 18 to Beta 18. If landed 11AM-5PM PT tomorrow on mozilla-beta, it will make the first FF18 Beta. If landed after that, it will end up in the second FF18 beta.
Attachment #679027 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fixed in the Firefox 18 beta 4 build.

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20121212073002
QA Contact: manuela.muntean
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: