Closed
Bug 1215180
Opened 9 years ago
Closed 8 years ago
[OMTA] CSS spin animation is blurry in scaled element
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla48
People
(Reporter: arni2033, Assigned: mantaroh)
References
Details
(Keywords: regression)
Attachments
(5 files, 2 obsolete files)
STR: (Win7_64, Nightly 44, 32bit, ID 20151012030612, new profile)
1. Open attached "testcase 1"
Result: Both circles sometimes become blurry at the left and right side
Expectations: No blur
It was regressed between 2015-06-30 and 2015-07-01:
> pushlog_url: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5e0f52d03e41fb437f1433291fb4747903166162&tochange=609e17393e2ee232e6545badc9c10caa3a116356
Second circle (::after pseudoelement) was ~ok before bug 771367
status-firefox41:
--- → affected
status-firefox42:
--- → affected
status-firefox43:
--- → affected
status-firefox-esr38:
--- → unaffected
Attachment #8674325 -
Attachment is obsolete: true
I suppose we could do these lines in ComputeScaleAndSetTransform: scale.width *= aIncomingScale.mXScale; scale.height *= aIncomingScale.mYScale; only when they make the scale larger, and not when they make it smaller. I'm not sure if that's a good idea, though.
Updated•8 years ago
|
Has Regression Range: --- → yes
status-firefox45:
--- → affected
status-firefox46:
--- → affected
status-firefox47:
--- → affected
status-firefox-esr45:
--- → affected
Version: Trunk → 41 Branch
Comment 6•8 years ago
|
||
Jet, do you have anyone on your team who could own this?
Flags: needinfo?(jst) → needinfo?(bugs)
Comment 7•8 years ago
|
||
(In reply to David Baron [:dbaron] ⌚️UTC-4 (less responsive until April 4) from comment #4) > I suppose we could do these lines in ComputeScaleAndSetTransform: > scale.width *= aIncomingScale.mXScale; > scale.height *= aIncomingScale.mYScale; > only when they make the scale larger, and not when they make it smaller. > I'm not sure if that's a good idea, though. Note that that function is now called ChooseScaleAndSetTransform.
Comment 8•8 years ago
|
||
Mantaroh is going to have a look into this.
Assignee: nobody → mantaroh
Flags: needinfo?(bugs)
Assignee | ||
Comment 9•8 years ago
|
||
Thanks brian. (In reply to Brian Birtles (:birtles) from comment #7) > (In reply to David Baron [:dbaron] ⌚️UTC-4 (less responsive until April 4) > from comment #4) > > I suppose we could do these lines in ComputeScaleAndSetTransform: > > scale.width *= aIncomingScale.mXScale; > > scale.height *= aIncomingScale.mYScale; > > only when they make the scale larger, and not when they make it smaller. > > I'm not sure if that's a good idea, though. > > Note that that function is now called ChooseScaleAndSetTransform. I investigating this phenomenon, I tried changing the scale calculating as comment #4. According to result image, perhaps this change will affect this bugs.
Assignee | ||
Comment 10•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=14b3372fe1f8
Assignee | ||
Comment 11•8 years ago
|
||
Previous modification is not work well when scale is larger than 1.0. hiro created the this condition test case. I modified the calculating of scale size. https://treeherder.mozilla.org/#/jobs?repo=try&revision=36ecbc564bdc
Assignee | ||
Comment 12•8 years ago
|
||
Hi Markus, I modified the calculating the scale size of transform. Couldn't you confirm this patch? Thanks.
Attachment #8733697 -
Flags: review?(mstange)
Comment 13•8 years ago
|
||
Comment on attachment 8733697 [details] [diff] [review] Modify the calculating the scale size of transformation. Review of attachment 8733697 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/base/FrameLayerBuilder.cpp @@ +5115,5 @@ > scale = nsLayoutUtils::ComputeSuitableScaleForAnimation( > aContainerFrame, aVisibleRect.Size(), > displaySize); > + // multiply by the scale inherited from ancestors--we use the maximum scale > + // size to prevent blurring. As discussed, I think we should refer to uniform scale and mention the fact that the blurring comes when we rotate. e.g. // multiply by the scale inherited from ancestors--we use a uniform // scale factor to prevent blurring when the layer is rotated.
Comment 14•8 years ago
|
||
Yes, please change the comment as Brian suggested.
Assignee | ||
Comment 15•8 years ago
|
||
Thanks markus, brian. (In reply to Markus Stange [:mstange] from comment #14) > Yes, please change the comment as Brian suggested. I addressed above comments. Could you please confirm again?
Attachment #8733697 -
Attachment is obsolete: true
Attachment #8733697 -
Flags: review?(mstange)
Attachment #8734160 -
Flags: review?(mstange)
Updated•8 years ago
|
Attachment #8734160 -
Flags: review?(mstange) → review+
Assignee | ||
Updated•8 years ago
|
Keywords: checkin-needed
Comment 17•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c0e81c5f1bc
Keywords: checkin-needed
Comment 18•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5c0e81c5f1bc
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Reporter | ||
Comment 19•8 years ago
|
||
Affected: Win7_64, Nightly 48, 32bit, ID 20160325085113 Fixed on: Win7_64, Nightly 48, 32bit, ID 20160326030430
Status: RESOLVED → VERIFIED
Comment 20•8 years ago
|
||
Too late for 46/47, but it's nice to see this fixed in 48.
You need to log in
before you can comment on or make changes to this bug.
Description
•