Closed
Bug 1258086
Opened 8 years ago
Closed 8 years ago
[GTK3] tooltip having transparent(alpha) style isn't painted correctly
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
mozilla49
People
(Reporter: euthanasia_waltz, Assigned: acomminos)
References
Details
(Keywords: regression)
Attachments
(7 files)
30.08 KB,
image/png
|
Details | |
29.88 KB,
image/png
|
Details | |
19.60 KB,
image/png
|
Details | |
20.81 KB,
image/png
|
Details | |
29.68 KB,
image/png
|
Details | |
353 bytes,
text/html
|
Details | |
58 bytes,
text/x-review-board-request
|
lsalzman
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
|
Details |
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);
>}
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.
Comment 7•8 years ago
|
||
Thanks for the nice clear bug report. This happens with gfx.xrender.enabled;false but not with true.
Blocks: 1241832
Status: UNCONFIRMED → NEW
status-firefox46:
--- → unaffected
status-firefox47:
--- → affected
Ever confirmed: true
Keywords: regression
Comment 8•8 years ago
|
||
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.
Comment 9•8 years ago
|
||
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.
tracking-firefox47:
--- → ?
Component: Widget: Gtk → Graphics
Updated•8 years ago
|
Updated•8 years ago
|
Assignee: nobody → andrew
Assignee | ||
Comment 10•8 years ago
|
||
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
Assignee | ||
Comment 11•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/49287/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/49287/
Attachment #8746182 -
Flags: review?(lsalzman)
Assignee | ||
Comment 12•8 years ago
|
||
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 13•8 years ago
|
||
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+
Assignee | ||
Comment 14•8 years ago
|
||
Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d83558554d97
Comment 16•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0aa740ece69e
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment 17•8 years ago
|
||
Recent regression, tracking Want to request uplift to 47?
Flags: needinfo?(andrew)
Assignee | ||
Comment 18•8 years ago
|
||
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?
Updated•8 years ago
|
status-firefox48:
--- → affected
tracking-firefox48:
--- → +
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+
Comment 21•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/b059ea150b9e
Comment 22•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/3d7688da70b6
Reporter | ||
Comment 23•8 years ago
|
||
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)
(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
You need to log in
before you can comment on or make changes to this bug.
Description
•