Closed Bug 584699 Opened 10 years ago Closed 10 years ago
Redraw issues when moving elements with -moz-transform rotate applied
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
Adding mitcho and aza, who've both seen this as well.
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?
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?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(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.
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.
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
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
Attachment #463659 - Attachment is obsolete: true
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
Summary: Font redraw issues when moving tabs → Redraw issues when moving elements with -moz-transform rotate applied
Component: TabCandy → Layout
Product: Mozilla Labs → Core
QA Contact: tabcandy → layout
Target Milestone: -- → ---
Assignee: nobody → roc
blocking2.0: --- → betaN+
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
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.
Depends on: 579323
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 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?
Attachment #464378 - Flags: review?(dbaron) → review+
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.)
Whiteboard: tabcandy → tabcandy [needs landing]
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);
http://hg.mozilla.org/mozilla-central/rev/1f08cbe27e32 Followup fix to test for D2D: http://hg.mozilla.org/mozilla-central/rev/568b83539705
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: tabcandy [needs landing] → tabcandy
You need to log in before you can comment on or make changes to this bug.