Closed
Bug 970294
Opened 11 years ago
Closed 11 years ago
Perspective + Box-shadow leads to incorrect box size model when transform-ing
Categories
(Core :: Graphics: Layers, defect)
Core
Graphics: Layers
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: bugzilla, Assigned: mattwoodrow)
References
Details
(Keywords: regression, Whiteboard: [good first verify])
Attachments
(1 file)
(deleted),
patch
|
nrc
:
review+
Sylvestre
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140205162153
Steps to reproduce:
Created an fixed size object with these css properties applied :
- ouset box-shadow (either one of 4 props set)
- perspective
- transform3D with deg != 0%180
Test case here : http://jsfiddle.net/LPUTa/3/
Actual results:
Object is transformed as if its size was increased by the shadow's pixels
Expected results:
Object should transform using it's own size, and shadow should not interfere.
Notes:
1/ If the angle is multiple of 180, this doesn't happen. Therefore, an animation/transition using this combination of attributes appears flickering (for example : http://css3playground.com/3d-flip-cards/)
2/ This is a regression : was OK in Firefox 27.
Comment 1•11 years ago
|
||
Antwan, what part of the testcase is the part I should be looking at here?
What I see is that the behavior of the third div in the "perspective" set seems to depend on window width, and in particular on the line-wrapping(?).
The 3rd element of the 2nd line should be positioned like the 1st element of the second line.
Comment 3•11 years ago
|
||
OK. So for what it's worth, it doesn't seem to be in Firefox 27, for me...
Comment 4•11 years ago
|
||
I loaded the testcase in Firefox 26RC, 27RC, 28beta3, Aurora 29, Nightly 30, Internet Explorer and all browsers display the same result. Am I missing something?
Flags: needinfo?(antwan)
Comment 5•11 years ago
|
||
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #4)
> I loaded the testcase in Firefox 26RC, 27RC, 28beta3, Aurora 29, Nightly 30,
> Internet Explorer and all browsers display the same result.
The result that I`m talking about can be seen in this screenshot http://bit.ly/1nT3Owe
Was happening only when hardware acceleration was disabled.
Try it on Firefox 27 vs Firefox 28 with both layers.acceleration.disabled:true.
As this setting is not defaulted, I'm not sure it's worth further investigation.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(antwan)
Resolution: --- → INVALID
Comment 7•11 years ago
|
||
Hardware accel can get disabled for all sorts of reasons....
Status: RESOLVED → REOPENED
Component: Layout: View Rendering → Graphics
Ever confirmed: true
Resolution: INVALID → ---
Comment 8•11 years ago
|
||
Ok so with hardware acceleration off I was able to reproduce the issue and got this regression range:
Central:
Last good revision: 53d55d2d0a25 (2013-11-26)
First bad revision: 6ecf0c4dfcbe (2013-11-27)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=53d55d2d0a25&tochange=6ecf0c4dfcbe
Inbound:
Last good revision: c9ff42335f8a
First bad revision: 35014d18ff1f
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c9ff42335f8a&tochange=35014d18ff1f
If you need any more assistance from QA please let me know.
Keywords: qawanted,
regressionwindow-wanted
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 28 Branch → Trunk
Comment 9•11 years ago
|
||
Bogdan, that's awesome, thank you!
Blocks: 932888
tracking-firefox28:
--- → ?
tracking-firefox29:
--- → ?
tracking-firefox30:
--- → ?
Component: Graphics → Graphics: Layers
Flags: needinfo?(ncameron)
Updated•11 years ago
|
status-firefox27:
--- → unaffected
status-firefox28:
--- → affected
status-firefox29:
--- → affected
status-firefox30:
--- → affected
Comment 10•11 years ago
|
||
I expect this is due to a bug in Azure somewhere - i.e., previously we were using Thebes for drawing and pot-bug 932888 we use Azure for that and so it goes wrong. Passing over to mattwoodrow who knows all about Azure vs Thebes and the basic layer manager.
Flags: needinfo?(ncameron) → needinfo?(matt.woodrow)
Assignee | ||
Comment 11•11 years ago
|
||
I see what the bug is, caused by http://hg.mozilla.org/integration/mozilla-inbound/rev/c38b37bee015.
Previously we set a device offset on the intermediate surface, with Azure we instead set a transform on the context.
Unfortunately BasicLayerManager::PaintLayer can clobber the transform (but not the device offset of a gfxASurface), so this gets lost.
I'll have a think about the best way to fix this.
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 12•11 years ago
|
||
This way the users of the gfxContext can't clobber our device offset.
Attachment #8383220 -
Flags: review?(ncameron)
Comment 13•11 years ago
|
||
Comment on attachment 8383220 [details] [diff] [review]
Use gfxContext's device offset functionality
Review of attachment 8383220 [details] [diff] [review]:
-----------------------------------------------------------------
::: gfx/layers/basic/BasicLayerManager.cpp
@@ +959,5 @@
> if (!untransformedDT) {
> return;
> }
>
> + nsRefPtr<gfxContext> groupTarget = new gfxContext(untransformedDT, Point(bounds.x, bounds.y));
nit: long line
::: gfx/thebes/gfxContext.h
@@ +50,5 @@
> * Initialize this context from a DrawTarget.
> * Strips any transform from aTarget.
> * aTarget will be flushed in the gfxContext's destructor.
> */
> + gfxContext(mozilla::gfx::DrawTarget *aTarget, const mozilla::gfx::Point& aDeviceOffset = mozilla::gfx::Point());
nit: long line
Attachment #8383220 -
Flags: review?(ncameron) → review+
Assignee | ||
Comment 14•11 years ago
|
||
Comment 15•11 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Assignee | ||
Comment 16•11 years ago
|
||
Comment on attachment 8383220 [details] [diff] [review]
Use gfxContext's device offset functionality
[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 932888.
User impact if declined: Incorrect 3d transform rendering without hardware acceleration.
Testing completed (on m-c, etc.): Been on m-c for a week, confirmed testcase
Risk to taking this patch (and alternatives if risky): Low risk, just changes a transform matrix.
String or IDL/UUID changes made by this patch: None
Attachment #8383220 -
Flags: approval-mozilla-beta?
Attachment #8383220 -
Flags: approval-mozilla-aurora?
Updated•11 years ago
|
Attachment #8383220 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 17•11 years ago
|
||
Updated•11 years ago
|
Whiteboard: [good first verify]
Updated•11 years ago
|
Attachment #8383220 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 18•11 years ago
|
||
Comment 19•11 years ago
|
||
Updated•11 years ago
|
status-b2g-v1.3:
--- → fixed
status-b2g-v1.4:
--- → fixed
Updated•11 years ago
|
status-b2g-v1.3T:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•