Closed Bug 1215180 Opened 9 years ago Closed 8 years ago

[OMTA] CSS spin animation is blurry in scaled element

Categories

(Core :: Layout, defect)

41 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox41 --- affected
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- verified
firefox-esr38 --- unaffected
firefox-esr45 --- affected

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
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.
Has STR: --- → yes
Jst - can you find an owner?
Flags: needinfo?(jst)
Jet, do you have anyone on your team who could own this?
Flags: needinfo?(jst) → needinfo?(bugs)
(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.
Mantaroh is going to have a look into this.
Assignee: nobody → mantaroh
Flags: needinfo?(bugs)
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.
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
Hi Markus,

I modified the calculating the scale size of transform.
Couldn't you confirm this patch?

Thanks.
Attachment #8733697 - Flags: review?(mstange)
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.
Yes, please change the comment as Brian suggested.
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)
Attachment #8734160 - Flags: review?(mstange) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/5c0e81c5f1bc
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Affected:   Win7_64, Nightly 48, 32bit, ID 20160325085113
Fixed on:   Win7_64, Nightly 48, 32bit, ID 20160326030430
Status: RESOLVED → VERIFIED
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.