963025 - Animation glitch with two rows items in the panel

Status: RESOLVED WORKSFORME

(Firefox :: Toolbars and Customization, defect)

Description

[u428464]

With the new default font size for widgets in the menu panel the animation make the second row disappears. It's not very nice visually. New Private Window for example is affected.

Comment 1

[u428464]

(In customization mode)

Comment 2

[u428464]

Attachment: Appearance of two row items while dragging.png

Here is what it looks like.

Comment 3

[u428464]

That may be caused by the fact that the widgets are closer to each other in customization mode than in the menu panel (which is strange BTW)

Comment 4

[:Gijs (he/him)]

This doesn't make sense to me, though... we're just transform'ing that item. It's not being dragged - there shouldn't be any changes to its size.

Comment 5

[u428464]

(In reply to :Gijs Kruitbosch from comment #4)
> This doesn't make sense to me, though... we're just transform'ing that item.
> It's not being dragged - there shouldn't be any changes to its size.

I think the item beneath it may cover the second row of text.

It's a bit the same in customization mode with the "g" of "character encoding" that is cut.

Comment 6

[:Gijs (he/him)]

(In reply to Guillaume C. [:ge3k0s] from comment #5)
> (In reply to :Gijs Kruitbosch from comment #4)
> > This doesn't make sense to me, though... we're just transform'ing that item.
> > It's not being dragged - there shouldn't be any changes to its size.
> 
> I think the item beneath it may cover the second row of text.
> 
> It's a bit the same in customization mode with the "g" of "character
> encoding" that is cut.

But I *think* the background-color of all the items has a fully transparent alpha component, that is, isn't opaque. So it shouldn't be doing that, either.

Mike, do you have ideas?

Comment 7

[Mike de Boer [:mikedeboer]]

Just FYI, I can't reproduce this on OSX... continuing on other platforms...

Comment 8

[Mike de Boer [:mikedeboer]]

This is what's happening, at least what I'm seeing more clearly atm:

While dragging, the font rendering is going, let's say, 'apeshit':
* On OSX HiDPI, the font rendering goes wonky, which seems like a combination of aliasing and kerning being skipped or something. I suspect that this is also the case on non-retina OSX boxes, but less noticeable.
* On Windows, labels in the middle column jump a bit leftward and indeed, the second row of text of multi-line labels are chopped off for ~80%.

So I'm putting my money on a problem with text handling in gfx/ layout. When you hold your mouse still for a second, the rendering of text labels is corrected; let's call it a final render pass. A perf optimization?

Since this only happens while dragging an icon, I'm putting the prio down to P5.

Matt, are you the right person to ask for a possible explanation of this?

Comment 9

[Matt Woodrow (:mattwoodrow)]

Can you get a screencast or similar of the behaviour you're seeing? In particular, I'd like to see what 'apeshit' looks like.

My guesses:

Initiating the drag puts that content into a separate retained buffer (layer) so that we can reposition it without doing any content drawing. This retained buffer only has the icon and text, no background color. Without a background color we can't compute the correct values to do subpixel antialising on the text. So either we're disabling subpixel AA, or we're doing it and coming up with awful results.

As for the text being obscured, that looks like an issue with the page, not the layout engine. Are you sure the images have a transparent background? Adding the transform property to an element makes it a stacking context, which affects painting order. It seems pretty plausible that this would result in the image drawing on top of the text, and obscuring it.

Comment 10

[:Gijs (he/him)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> Can you get a screencast or similar of the behaviour you're seeing? In
> particular, I'd like to see what 'apeshit' looks like.
> 
> My guesses:
> 
> Initiating the drag puts that content into a separate retained buffer
> (layer) so that we can reposition it without doing any content drawing. This
> retained buffer only has the icon and text, no background color. Without a
> background color we can't compute the correct values to do subpixel
> antialising on the text. So either we're disabling subpixel AA, or we're
> doing it and coming up with awful results.
> 
> As for the text being obscured, that looks like an issue with the page, not
> the layout engine. Are you sure the images have a transparent background?
> Adding the transform property to an element makes it a stacking context,
> which affects painting order. It seems pretty plausible that this would
> result in the image drawing on top of the text, and obscuring it.

The thing is, the dragging thing isn't what being drawn incorrectly. It's the other elements which are CSS transform'd to have a different position. For those, it's the toolbarbutton/toolbaritem that's being transformed. The buttons have transparent pngs inside a XUL image (inside XBL) and a multiline XUL label. It's the latter of these that is getting cut off, but the background of the image as well as the toolbarbutton is transparent, which means them cutting off doesn't make much sense. And yes, I'm sure that the image has a transparent background. If it matters, though, the toolbarbutton has an hsla(x, y, z, 0) background, perhaps that's not being handled correctly?

Comment 11

[:Gijs (he/him)]

Attachment: drag-cutoff.png

Comment 12

[:Gijs (he/him)]

Attachment: drag-behaviour.ogg

Comment 13

[:Gijs (he/him)]

(I tried setting the background-color to 'transparent', that doesn't seem to make any difference)

Matt, does this screencast help?

Comment 14

[Matt Woodrow (:mattwoodrow)]

Most of that seems to make sense. Even though it's not the item being dragged, it's still an item being animated using transform.

The text in this moving item is clearly getting subpixel AA disabled (for the reason I mentioned above), which makes sense. Putting a solid background color behind the text (but still part of the moving element) would fix that, but might not have the visual effect you want.

Comment 15

[Matt Woodrow (:mattwoodrow)]

I can reproduce this in a nightly, but not a local build.

It's possible that this is caused by the SDK used (10.6 vs 10.8?9?), would be good to confirm that.

Comment 16

[:Gijs (he/him)]

I can reproduce the text cutoff locally when building with the 10.8 SDK but not with the 10.9 SDK. I guess that means this belongs in Core somewhere, but I don't know where...

(In reply to Guillaume C. [:ge3k0s] from comment #0)
> With the new default font size for widgets in the menu panel the animation
> make the second row disappears. It's not very nice visually. New Private
> Window for example is affected.

Guillaume, you reproduced this on Windows, right? (that's what the screenshot looks like to me, at least...)

Comment 17

[u428464]

(In reply to :Gijs Kruitbosch from comment #16)
> (In reply to Guillaume C. [:ge3k0s] from comment #0)
> > With the new default font size for widgets in the menu panel the animation
> > make the second row disappears. It's not very nice visually. New Private
> > Window for example is affected.
> 
> Guillaume, you reproduced this on Windows, right? (that's what the
> screenshot looks like to me, at least...)

Yes you're assuming right. Win 7 :-)

Comment 18

[:Gijs (he/him)]

(In reply to Guillaume C. [:ge3k0s] from comment #17)
> (In reply to :Gijs Kruitbosch from comment #16)
> > (In reply to Guillaume C. [:ge3k0s] from comment #0)
> > > With the new default font size for widgets in the menu panel the animation
> > > make the second row disappears. It's not very nice visually. New Private
> > > Window for example is affected.
> > 
> > Guillaume, you reproduced this on Windows, right? (that's what the
> > screenshot looks like to me, at least...)
> 
> Yes you're assuming right. Win 7 :-)

I'm guessing this is fixed in builds with bug 897496 fixed. Am I correct? :-)

Comment 19

[u428464]

Yes this seeems fixed at least with two rows items. I can't test with widgets that have longer labels but I assume it's fixed in their case too.