584699 - Redraw issues when moving elements with -moz-transform rotate applied

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Matthew Galloway]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100802 Minefield/4.0b3pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100802 Minefield/4.0b3pre

Watch this video I recorded to demonstrate the problem:
http://www.youtube.com/watch?v=QSV6mk-Y6mQ
If the video isn't clear: when I move a tab around, the title of the tab gets all mangled and starts overlapping on itself, as does the favicon in the corner. 
I've tried restarting minefield after I closed all of my tabs but the problem still persists. 

Reproducible: Always




Built from http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/a0ccb8c47ab8

Comment 1

[Ian Gilman [:iangilman]]

Adding mitcho and aza, who've both seen this as well.

Comment 2

[Ian Gilman [:iangilman]]

I figure it must be something that happened in the browser... hard to imagine we did it in the Tab Candy code. Perhaps it has something to do with our use of CSS transitions? Some hardware acceleration thing that recently kicked in and isn't working quite right?

Comment 3

[Michael Yoshitaka Erlewine [:mitcho]]

Matthew, thanks. Yes, I've seen this as well, though I'd thought perhaps this was an issue with my machine/graphics. I also noticed that this started to happen with the (old) TabCandy xpi on the Minefield nightly... perhaps something changed in the platform in the past week or two to cause this?

Comment 4

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #2)
> I figure it must be something that happened in the browser... hard to imagine
> we did it in the Tab Candy code. Perhaps it has something to do with our use of
> CSS transitions? Some hardware acceleration thing that recently kicked in and
> isn't working quite right?

Agreed. Let me try making a test case outside of tabcandy.

Comment 5

[Aza Raskin [:aza]]

My guess is that this has to do with turning on hardware acceleration. I found that when I was experimenting with the accelerated=11 thing I would get similar odd tearing. If the hunch is correct, it should only affect canvas elements and not images.

Comment 6

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: test case

A non-tabcandy test case which can reproduce this issue in my tabcandy build and my nightly.

My nightly is:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre

Comment 7

[Michael Yoshitaka Erlewine [:mitcho]]

Attachment: test case v2

A slightly simpler test case. Same target environment as the last one:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre

Comment 8

[Matthew Galloway]

Causes aliasing for me as well. 

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre
Built from http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/42757fc4edcc

Comment 9

[Michael Yoshitaka Erlewine [:mitcho]]

In the mean time, I've committed a quick "fix" to this issue in Tab Candy so that, in those many cases where we actually set an item to have a rotation of 0, we remove the "-moz-transform" property instead of setting it to "rotate(0deg)".

http://hg.mozilla.org/users/edward.lee_engineering.uiuc.edu/tabcandy-central/rev/25f899d30418

Comment 10

[Bas Schouten (:bas.schouten)]

Attachment: Transformed Layer's Texture

So, I've attached here the texture of the square that is being moved at some point in time. What is happening is that the visible region is changed, as expected. It moves down, the part that is newly visible will then be invalidated. The part that is already visible will be retained.

There will be nothing invalidating the previous bottom border of the square. Causing it to remain on the retained texture as a rogue horizontal line. A new bottom line will be drawn in the invalidated texture and it will form a rogue line upon the next update, etc.

Comment 11

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

Attachment: fix

This fix depends on the patches attached to bug 579323. Calling InvalidateOverflowRect on the abs-pos child forces any ThebesLayers for ContainerLayers under it to be completely invalidated.

Comment 12

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

Attachment: fix v2

Updated for changes in bug 579323

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 464378 [details] [diff] [review]
fix v2

r=dbaron, although it feels to me like we shouldn't need this.  Do you know why we do?

Comment 14

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

See comment in bug 579323. Moving a frame does not move the layer contents automatically. The layer contents have to be repainted. (Unless the moving frame is a scrolled frame ... if we wanted to, we could add other types of frames to nsLayoutUtils::GetActiveScrolledRoot.)

Comment 15

[Nate Weiner]

Ian suggested I make a note of where I've seen this as well:

Setting opacity seems to trigger the ghosting too.  Here is a video example:
http://www.screencast.com/users/ideashower/folders/Jing/media/c0cc22a2-ee14-4aa2-9f99-fb35a7acc784

When the tab is dragged over the black box the tabItem container is set to 50% opacity.  Once opacity is less than 100% it begins showing the effect.

This also applies to setting the background-color property to something like: rgba(255,255,255,0.5);

Comment 16

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

http://hg.mozilla.org/mozilla-central/rev/1f08cbe27e32
Followup fix to test for D2D:
http://hg.mozilla.org/mozilla-central/rev/568b83539705