637597 - Drawing errors while moving nodes with css3 transforms inside scaled node.

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[tonistiigi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.102 Safari/534.13
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

Translate element inside scaled element. During the change for ~1sec all elements inside the scaled parent are drawn wrong. This may result in child elements appearing 1px smaller or larger of single lines left on the edge.

Reproducible: Always

Steps to Reproduce:
1. Go to http://limejs.digitalfruit.ee/ff4/d_ff4_scale_bug.htm
2. Look at the source
3.
Actual Results:  
Weird artifact happen during the move.

Usually: red and green box appear 1px bigger during the move. This is specially annoying for the red box that is supposed to be completely static.

On one machine: In addition to resize issues bottom line of green box still remains on 400px. So there is a red box, a green box and a green line on the screen. This does not go away after 1 sec.

Expected Results:  
Green box should move 200px up. Red box should remain unchanged.

Does not appear on Firefox3.6 or in any other browser.

Appears both mac and windows.

Also appears if moved with transitions. Then appears as long as the duration of the transition.

Seems that only appear when moved with -moz-transform: translate(). Ok if moved with left/top.

First it seemed to me that resize happened when scale_factor*element_size was a value where round(num)!=ceil(num). But not sure any more as I have seen different result on different machines.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Probably bug 635373.

Comment 2

[tonistiigi]

This was marked as probably same as bug 635373 "Small artifacts appear then disappear with hardware acceleration" . Just to clear that this one also appeared when I turned hardware acceleration OFF from the preferences and restarted Firefox.

Comment 3

[Mats Palmgren (inactive)]

I can reproduce it on Linux x86-64, with no HW acceleration.
Regression window:  2010-08-01-03 -- 2010-08-02-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=070d9d46d88b&tochange=a4d86c3a3494

Comment 4

[Mats Palmgren (inactive)]

The behavior is slightly different in 2010-08-02-03 though;
the red box has sharp edges at first then is blurred then sharp again.
I'll try to find the second regression range when it changed to the
current behavior.

Comment 5

[Mats Palmgren (inactive)]

The second regression range:  2010-11-07-03 -- 2010-11-08-04
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8cbe83542596&tochange=a0826dcd6228

Comment 6

[Mats Palmgren (inactive)]

Attachment: Reporter's testcase

Comment 7

[tonistiigi]

This bug is marked as dependent from bug 635373 which is now marked as fixed. It still appears on latest Minefield(01/04)

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The problem here is almost certainly a difference in rendering between an inactive transform and an active transform. The latter uses an intermediate temporary surface and the former does not. In the latter case elements b1 and b2 are rendered to temporary buffers which are then transformed by the GPU, and their edges are aliased by GPU compositing. In the former case the elements are transformed via cairo and their edges are snapped by our normal snapping algorithm, which is different.

Some of the symptoms described above have been fixed by bug 635373 or other bugs. The only symptom I see now is the boxes appearing to change size by 1px temporarily.

I'm not sure we can do much here without breaking other things.

Comment 9

[tonistiigi]

Are you saying that this will probably never get fixed? This is a major feature for RIAs and games. Nobody is going to use an application that flickers all the time. Might as well call all CSS transformations part unusable. Similar issue is also when parent node is rotated(aliasing difference). At the moment a feature has been made 50% faster(layers framework) by not supporting it any more. There should at least be a way to turn off this new fancy GPU rendering until it gets reasonably stable.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's an exaggeration. Most uses of transforms don't have a problem here. Making the software renderer and the GPU compositor match their rendering exactly is not feasible.

Comment 11

[tonistiigi]

Its not. Whole point of CSS transforms is that you can set a transformation matrix for the element. As far as I can see this feature only works if only translation segments of this matrix are filled. That means 2 out of 6. Same way would be to say one can set an elements width but only in ranges 10-60, 110-140, 190-210 etc.

I'm not saying this is easy. I'm sure its very hard but you should advertise it as a feature or force it to all webpages unless it is really working.

I don't wish to be rude. Its just very hard for me to explain why I can't fix the code that worked perfectly in FF3 and even works in browsers like IE9 but does not work in FF4 that should be that best browser to use at the moment.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #11)
> As far as I can see this feature only works if only
> translation segments of this matrix are filled. 

Nope. Lots of pages use transforms and work great. You have hit an edge case that is particularly hard to handle.

However, the work in bug 637852 should fix this.

Comment 13

[tonistiigi]

Just letting everybody know that I have found a workaround. On every animationframe(or timeout) when transforms change switch document.body transform style between "scale(1,1)" and "". I guess this forces redraw and layers framework isn't used. I'm sure its very bad for performance(probably same as FF3.6) but at least it works.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Should have been fixed in bug 637852. Please retest on a nightly build.

Comment 15

[(no longer active)]

It turns out that this was never fixed in fact.  The original bug is reproducible on Mac at least.  Timothy also said that he can repro it using basic layers.

See bug 10209 comment 141 onwards...

Comment 16

[(no longer active)]

Note that I have marked the test for this bug as random: https://hg.mozilla.org/mozilla-central/rev/d5ec6fead55b

Comment 17

[Gregory Pappas [:gregp]]

Attachment: Firefox4 scale bug.html

Comment 18

[Gregory Pappas [:gregp]]

Unable to reproduce in recent versions.

Comment 19

[Gregory Pappas [:gregp]]

Attachment: Bug 637597 - Un-random the test for bug 637597 because it doesn't reproduce anymore r?dholbert!

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/afca22b7f37d
Un-random the test for bug 637597 because it doesn't reproduce anymore r=dholbert

Comment 21

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/afca22b7f37d