Closed Bug 1258086 Opened 4 years ago Closed 4 years ago

[GTK3] tooltip having transparent(alpha) style isn't painted correctly

Categories

(Core :: Graphics, defect)

Unspecified
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla49
Tracking Status
firefox46 --- unaffected
firefox47 + fixed
firefox48 + fixed
firefox49 --- verified

People

(Reporter: euthanasia_waltz, Assigned: acomminos)

References

Details

(Keywords: regression)

Attachments

(7 files)

Tooltip with transparent style is normal at first time but it is gradually corrupted.
Following screenshots are taken on manjaro-linux-xfce.(gtk 3.18.8)
They can be reproduced on LinuxMint(gtk 3.10.8) also with having ~/.config/gtk-3.0/gtk.css.
e.g.
>.tooltip {
>  color: rgb(255,255,255);
>  background-color: rgba(64,64,64,0.5);
>}
Attached image 5th, ...
This broken tooltip is not appeared constantly. It becomes sometimes normal. It becomes as if being mixed with previous one. It becomes as if being mixed with another(not previous) one. ...

If there is no transparency,
e.g.
>.tooltip {
>  color: rgb(255,255,255);
>  background-color: rgb(64,64,64);
>}
this problem won't occur.
Blocks: gtk3
Thanks for the nice clear bug report.
This happens with gfx.xrender.enabled;false but not with true.
Blocks: 1241832
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Attached file testcase 1
I can reproduce this as well on Ubuntu Linux 16.04 with gnome-shell and default Ambiance theme.

Testcase attached. For me, the tooltip border in the testcase is noticeably darker on the 1st hover (when it's nearly the same as the tooltip-background color) as compared to the 4th/5th hover (when it's nearly the same as the tooltip-text color).

And I can confirm karlt's report that this bug goes away if I set the pref gfx.xrender.enabled to true.
See Also: → 1262995
I suspect this is a graphics problem (even if the code may live in widget/gtk) with a surface not being initialized to clear for the paint, or operator over used instead of operator source somewhere.

[Tracking Requested - why for this release]:
Noticeable regression that can make tooltips hard to read.
Component: Widget: Gtk → Graphics
Blocks: 1262995
See Also: 1262995
Assignee: nobody → andrew
The issue here appears to be that we aren't properly clearing a reused SHM image in response to an expose event. Since we use X11 SHM unbuffered (with BufferMode::BUFFER_NONE), the basic layer manager draws directly to the SHM image using an arbitrary composition operator, unlike our XRender path which is buffered and draws to the window using the source operator (which is why this isn't occurring with XRender on). I'll look into why the layer manager isn't clearing unbuffered DTs properly.
Status: NEW → ASSIGNED
AFAICT, it's not the responsibility of the layer manager to ensure the surface it draws into is "clean"- this patch ensures that we explicitly clear unbuffered RGBA surfaces before drawing with basic layers in response to an expose. Otherwise, we don't care what composition operator is used.

Thanks!
Comment on attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

https://reviewboard.mozilla.org/r/49287/#review46197

Seems like it should work.
Attachment #8746182 - Flags: review?(lsalzman) → review+
https://hg.mozilla.org/mozilla-central/rev/0aa740ece69e
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Recent regression, tracking
Want to request uplift to 47?
Flags: needinfo?(andrew)
Comment on attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

Sure, sounds good.

Approval Request Comment
[Feature/regressing bug #]: Bug 1180942
[User impact if declined]: Tooltips will show artifacts after a redraw on Linux.
[Describe test coverage new/current, TreeHerder]: N/A
[Risks and why]: Small risk, merely clears a surface already expected to be clear before painting.
[String/UUID change made/needed]: N/A
Flags: needinfo?(andrew)
Attachment #8746182 - Flags: approval-mozilla-beta?
Attachment #8746182 - Flags: approval-mozilla-aurora?
Hello Atlanto, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(euthanasia_waltz)
Comment on attachment 8746182 [details]
MozReview Request: Bug 1258086 - Clear unbuffered SHM images with a 32-bit visual before drawing with the basic layer manager. r?lsalzman

Recent regression in Fx47, Aurora48+, Beta47+
Attachment #8746182 - Flags: approval-mozilla-beta?
Attachment #8746182 - Flags: approval-mozilla-beta+
Attachment #8746182 - Flags: approval-mozilla-aurora?
Attachment #8746182 - Flags: approval-mozilla-aurora+
Verified with latest nightly(build 20160506052037) on manjaro-linux(gtk3 3.20.3-1) and inuxmint(3.10.8~8+qiana).
It works very fine. Thanks.
Flags: needinfo?(euthanasia_waltz)
Duplicate of this bug: 1262995
(In reply to atlanto from comment #23)
> Verified with latest nightly(build 20160506052037) on manjaro-linux(gtk3
> 3.20.3-1) and inuxmint(3.10.8~8+qiana).
> It works very fine. Thanks.

Great! Thank you for the verification.
Status: RESOLVED → VERIFIED
No longer blocks: 1263222
You need to log in before you can comment on or make changes to this bug.