Closed
Bug 1304637
Opened 8 years ago
Closed 8 years ago
window not repainted after some kinds of expose events on Linux/x86_64
Categories
(Core :: Graphics, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla52
People
(Reporter: riksoft, Assigned: acomminos)
References
Details
(Keywords: regression, Whiteboard: [gfx-noted])
Attachments
(4 files)
157.23 KB,
image/jpeg
|
Details | |
58.45 KB,
image/png
|
Details | |
6.60 KB,
patch
|
lsalzman
:
review+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
2.90 KB,
patch
|
lsalzman
:
review+
gchang
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160811141523 Steps to reproduce: When I move any kind of window over Firefox window, it leaves a trail. (See attached image). Firefox Develper Edition 50.0a2 (2016-09-19). Alfa channel. Not happening on normal Firefox (v 48) Linux Mint 18 Kernel 4.4.0-36-generic Double monitor (but it happens on both) 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) No proprietary drivers. Window Manager: Marco (Composite disabled) Actual results: The window that I move over the Firefox window leave a trail and the content becomes a mess. It only get cleared when the Firefox window get the focus. Expected results: Firefox window not turning in a mess.
Could you type about:support in the location bar and copy the "graphics" section, please. In addition, could you narrow down a regression range with the tool Mozregression: http://mozilla.github.io/mozregression/(you'll need python 2.7) Run the command mozregression --good=48 then copy the final pushlog from repository mozilla-inbound.
Component: Untriaged → Graphics
Flags: needinfo?(riksoft)
Keywords: regressionwindow-wanted
Product: Firefox → Core
Link is http://mozilla.github.io/mozregression/ ofc.
(In reply to Loic from comment #1) > Could you type about:support in the location bar and copy the "graphics" > section, please. Attached > In addition, could you narrow down a regression range... Well... the 48 is working OK. The 50 has the problem, so it's certanly the v.49
Yes, it seems to be a regression in Aurora/Nightly, that's why Mozregression will help to find the offending regressing bug to fix it.
First I have to see how it works because I've never use mozregression before, plus, I have firefox standard and developer so I have to find out how can I affect only one profile/executable. I'm going to take a look at the documentation.
I've tried to install mozregression both from the monolithic gui tar and command line. The gui is outdated and reach only v 48 (and however doesn't work). The command line gives me tons of errors and resolving one I get another fresher error, starting from permission (even with sudo... I had to set chmod 777 -R con the pip cache), and going on...
I finally made it with great pain! :-) Now I've started from 48: good it then load 52a1: bad it then load 50 (50.0a1 (2016-07-06)): good it then load 51a1 (51.0a1 (2016-08-14)) : bad it then load 50.0a1: bad it then load 50.0a1 (50.0a1 (2016-07-17)) : good It is now focusing on same version but different dates/builds and after other 6 shots the winner is.... ==== 50.0a1 (2016-07-19) 20160719030224 ==== is the last one working properly. 16:20.25 INFO: Narrowed inbound regression window from [feaaf1af, 5a91e5b4] (3 revisions) to [feaaf1af, 37cc0da0] (2 revisions) (~1 steps left) 16:20.25 INFO: Oh noes, no (more) inbound revisions :( 16:20.25 INFO: Last good revision: feaaf1af1065257b9178faca8b67eed9657b4a17 16:20.25 INFO: First bad revision: 37cc0da01187534ea9f8d384c0c9c5c57eb67b56 16:20.25 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=feaaf1af1065257b9178faca8b67eed9657b4a17&tochange=37cc0da01187534ea9f8d384c0c9c5c57eb67b56 I don't know if there is a way to narrow more than that.
Reporter | ||
Comment 10•8 years ago
|
||
I didn't know about the option for the repo (the previous was on mozilla-central). Trying again with mozilla-aurora I've got different results sudo /usr/local/bin/mozregression --repo=mozilla-aurora '--good=2016-07-19 03:02:24' --bad=2016-09-22 This is the final result 6:52.11 INFO: Running mozilla-aurora build built on 2016-08-01 13:49:14.961000, revision d2f65d99 7:04.88 INFO: Launching /tmp/tmpsuU9Rv/firefox/firefox 7:04.89 INFO: application_buildid: 20160801042123 7:04.89 INFO: application_changeset: d2f65d99fd51e5ee2f34d892115cc5d6c39a8ea9 7:04.89 INFO: application_name: Firefox 7:04.89 INFO: application_repository: https://hg.mozilla.org/releases/mozilla-aurora 7:04.89 INFO: application_version: 49.0a2 Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good 7:35.90 INFO: Narrowed inbound regression window from [fcdf4bb7, 70ee99f1] (3 revisions) to [d2f65d99, 70ee99f1] (2 revisions) (~1 steps left) 7:35.90 INFO: Oh noes, no (more) inbound revisions :( 7:35.90 INFO: Last good revision: d2f65d99fd51e5ee2f34d892115cc5d6c39a8ea9 7:35.90 INFO: First bad revision: 70ee99f185b48cb59a4ec701282bf6a3fd6ce3e3 7:35.90 INFO: Pushlog: https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=d2f65d99fd51e5ee2f34d892115cc5d6c39a8ea9&tochange=70ee99f185b48cb59a4ec701282bf6a3fd6ce3e3 7:36.88 INFO: Looks like the following bug has the changes which introduced the regression: https://bugzilla.mozilla.org/show_bug.cgi?id=911216 So with alfa repo the last date OK is: 20160801042123, version is 49.0a2 while with the central repo is the last OK is 20160719030224 v. 50.0a1 I don't understand why... Pick what you prefer. :-)
Comment 11•8 years ago
|
||
Thanks for the regression range. I think Andrew Comminos — Bug 1287463 - Use a separate X display for non-XRender basic composition paths. r=lsalzman is a good candidate as regressing bug. Andrew, can you check this issue if you have some time or NI? someone else at Mozilla.
status-firefox49:
--- → unaffected
status-firefox50:
--- → affected
status-firefox51:
--- → affected
status-firefox52:
--- → affected
tracking-firefox50:
--- → ?
tracking-firefox51:
--- → ?
tracking-firefox52:
--- → ?
Flags: needinfo?(riksoft) → needinfo?(andrew)
Keywords: regressionwindow-wanted → regression
Comment 12•8 years ago
|
||
Tracking 52+ for this window redraw issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•8 years ago
|
Reporter | ||
Comment 13•8 years ago
|
||
The problem is actually connected with compositing: Testing with composite enabled (Windows manager: Marco+composite) the problem disappears.
Comment 14•8 years ago
|
||
Ryan, it looks like you made a lot of changes in the area after Andrew Comminos implemented the initial compositor display connection change. It's a bit hard to track down the issue due to this reorganization. Could you take a look and see what's going on here?
Flags: needinfo?(ryanhunt)
Updated•8 years ago
|
Priority: -- → P3
Whiteboard: [gfx-noted]
Updated•8 years ago
|
Assignee: nobody → ryanhunt
Tracked since it's a recent regression.
Comment 17•8 years ago
|
||
I kicked off a try push with bug 1287463 and bug 1287666 backed out from beta, for the reporter to verify it fixes the problem. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9a008161e5d217dfb3694c20d150952f24df1a3f Since this is a new regression in 50, and since there hasn't been any movement here, we could even land these backouts in 50 to buy us another release cycle worth of time. Backing out these patches from 51 or higher will be more messy because Ryan's bug OOP compositor work landed on top of it in bug 1289251, but if needed we can back that out too.
Comment 19•8 years ago
|
||
Stealing title from bug 1307362 as it is more descriptive/useful.
Summary: Entire Window Redraw problem on firefox developer edition only → window not repainted after some kinds of expose events on Linux/x86_64
Comment 20•8 years ago
|
||
Rik, can you try the build at [1] to see if it fixes the problem for you? [1] https://archive.mozilla.org/pub/firefox/try-builds/kgupta@mozilla.com-9a008161e5d217dfb3694c20d150952f24df1a3f/try-linux64/firefox-50.0.en-US.linux-x86_64.tar.bz2
Flags: needinfo?(riksoft)
Reporter | ||
Comment 21•8 years ago
|
||
Yes it works!
Comment 22•8 years ago
|
||
Thanks! I'll put up the beta backout patch for review.
Flags: needinfo?(riksoft)
Comment 23•8 years ago
|
||
Attachment #8798164 -
Flags: review?(lsalzman)
Comment 24•8 years ago
|
||
Comment on attachment 8798164 [details] [diff] [review] Backout of bug 1287463 and bug 1287666 on beta (Gecko50) Review of attachment 8798164 [details] [diff] [review]: ----------------------------------------------------------------- This seems like really bad juju to back out in general, since it will reintroduce the error handling problems we were previously having, but for beta only it is acceptable. When we have time we reaalllly should find another way to resolve this since
Attachment #8798164 -
Flags: review?(lsalzman) → review+
Comment 25•8 years ago
|
||
Comment on attachment 8798164 [details] [diff] [review] Backout of bug 1287463 and bug 1287666 on beta (Gecko50) Approval Request Comment [Feature/regressing bug #]: bug 1287463 [User impact if declined]: On Linux with non-compositing window managers, the Firefox window doesn't repaint properly if other windows are dragged over it [Describe test coverage new/current, TreeHerder]: no automated coverage as far as I know [Risks and why]: this is a backout of the regressing bug (as well as an additional change that landed on top of it). This fixes the issue for Firefox 50 and buys us some time to fix it properly. [String/UUID change made/needed]: none
Attachment #8798164 -
Flags: approval-mozilla-beta?
Comment on attachment 8798164 [details] [diff] [review] Backout of bug 1287463 and bug 1287666 on beta (Gecko50) Patch backout, fix was verified on a try build by bug filer, Beta50+
Attachment #8798164 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 27•8 years ago
|
||
Landed the backout on beta: https://hg.mozilla.org/releases/mozilla-beta/rev/a2a0b43625d2f61a8ced13d3e172caf431264f2b Leaving this bug open since it still affects 51+.
Updated•8 years ago
|
Flags: qe-verify+
Comment 28•8 years ago
|
||
In bug 1289251 we continue to use the compositor X display which was introduced in bug 1287463. I'm not sure why using a separate display is causing this issue, but I can write a patch that will revert the behavior post bug 1289251 to use the behavior pre bug 1287463.
Assignee: ryanhunt → andrew
Flags: needinfo?(ryanhunt)
Comment 29•8 years ago
|
||
This patch should revert us back to the behavior before bug 1287463 if we can't figure out a fix. It doesn't revert the changes in bug 1287666, because I'm not sure if that's necessary.
Comment 30•8 years ago
|
||
Comment on attachment 8802511 [details] [diff] [review] Revert to using the window X display for basic composition paths. This seems reasonable. I'll get up some builds to test with this.
Attachment #8802511 -
Flags: review+
Comment 31•8 years ago
|
||
Rik, can you try the build here and see if it resolves the issue? https://archive.mozilla.org/pub/firefox/try-builds/lsalzman@mozilla.com-a9611881633cb5949be403359ab50387f20e027d/try-linux64/firefox-52.0a1.en-US.linux-x86_64.tar.bz2
Flags: needinfo?(riksoft)
Comment 32•8 years ago
|
||
I can't speak for Rik, but it does seem to fix the issue for me on a Linux system running the nouveau drivers. Here's my relevant about:support graphics info:
>Compositing: OpenGL
>Asynchronous Pan/Zoom: wheel input enabled; touch input enabled
>WebGL 1/2 Renderer: nouveau -- Gallium 0.4 on NVD9
>Description: nouveau -- Gallium 0.4 on NVD9
>Device ID: Gallium 0.4 on NVD9
>Driver version: 3.0 Mesa 13.0.0-rc1
>AzureCanvasAccelerated: 1
>AzureCanvasBackend: skia
>Decision Log/HW_COMPOSITING: force_enabled by user: Force-enabled by pref
>Decision Log/OPENGL_COMPOSITING: force_enabled by user: Force-enabled by pref
>AzureContentBackend: skia
>AzureFallbackCanvasBackend: none
>CairoUseXRender: 0
Reporter | ||
Comment 33•8 years ago
|
||
Sorry for being late... I was on vacation... :-) Yes the build you've linked works like a charm!
Updated•8 years ago
|
Flags: needinfo?(riksoft)
Flags: needinfo?(andrew)
Comment 34•8 years ago
|
||
Does this still happen for you with regular builds if OpenGL compositing is disabled? What about with OpenGL compositing on, but not using nouveau, i.e. nvidia driver or if available, intel igp/driver?
Flags: needinfo?(wisniewskit)
Comment 35•8 years ago
|
||
If you use a non-compositing window manager other than Marco, does this still occur?
Flags: needinfo?(riksoft)
Comment 36•8 years ago
|
||
Note that the problem also doesn't seem to exist for me on 48.0.2, though it does on the nightly channel (official binaries from Mozilla, nothing custom, running fresh profiles in either version with only the alterations mentioned below). I just tested the nightly with the Intel i915 driver on my IGP, Nouveau on my discrete card, and the Mesa software driver, all with and without hw accel on in Firefox (via the menus). I made sure only the relevant kernel modules were loaded at the time. The results were the same for all cases, just slightly more pronounced in cases with hw accel off. I also tried with gfx.xrender.enabled flipped in each case, which didn't seem to affect the results. I'm not sure if I'll be able to also try the nVidia binary driver anytime soon, as it will require me to downgrade X11, and I'm a bit busy lately to tinker that much with my config right now. Also, since I'm not experiencing the issue as severely as the reporter seems to be, I'll try to describe the behavior I'm seeing as best I can. Basically, while dragging other windows around over a backgrounded Firefox window, I can see that Firefox isn't repainting itself regularly, as though it's intermittently busy with things other than repainting (which stands to reason, though Chrome doesn't share this quirk). Yet sometimes it doesn't seem to be busy, and just doesn't repaint at all if I just leave things alone (until I move the mouse again for a bit or foreground the Firefox window). In some cases I can even cover the entire Firefox window up with ghost images of the window being dragged over it, and sometimes it's black pixels instead of ghosts (which it is seems to be random for any given tab I switch to, and it happened no matter which case I was testing). I noticed that the backgrounded window seems to repaint consistently when it's is animating something like a gif. In case more info helps, I'm running Xfce 4.12 with compositing disabled (though enabling compositing in Xfce doesn't seem to change anything). The Gentoo build of my Nouveau driver is xf86-video-nouveau-1.0.13. I'm running xorg-x11-7.4-r2, with mesa-13.0.0_rc1. Here are the about:support details for my Intel driver (Gentoo build xf86-video-intel-2.99.917_p20161007): >Compositing: OpenGL >Asynchronous Pan/Zoom: wheel input enabled; touch input enabled >WebGL Renderer: Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Desktop >WebGL2 Renderer: Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Desktop >Description: Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Desktop >Vendor ID: Intel Open Source Technology Center >Device ID: Mesa DRI Intel(R) Haswell Desktop >Driver Version: 3.0 Mesa 13.0.0-rc1 >AzureCanvasAccelerated: 1 >AzureCanvasBackend: skia >AzureContentBackend: skia >AzureFallbackCanvasBackend: none >CairoUseXRender: 0 And here are these are the details of my Mesa software driver: >Compositing: OpenGL >Asynchronous Pan/Zoom: wheel input enabled; touch input enabled >WebGL Renderer: VMware, Inc. -- Gallium 0.4 on softpipe >WebGL2 Renderer: VMware, Inc. -- Gallium 0.4 on softpipe >Description: VMware, Inc. -- Gallium 0.4 on softpipe >Vendor ID: VMware, Inc. >Device ID: Gallium 0.4 on softpipe >Driver Version: 3.0 Mesa 13.0.0-rc1 >AzureCanvasAccelerated: 1 >AzureCanvasBackend: skia >AzureContentBackend: skia >AzureFallbackCanvasBackend: none >CairoUseXRender: 0
Flags: needinfo?(wisniewskit)
Reporter | ||
Comment 37•8 years ago
|
||
For me was OK om Firefox 48 and is still OK on Firefox 49. The problem is only on the Developer Edition because is on Alfa Channel and from 50.0a1 there is something wrong with disabled compositing. I can add that the same problem happens with Metacity without compositing. About OpenGL I have no idea how to change it's options or disable it completely without uninstalling Mesa. By the way it's the computer I work on so I'd like to avoid messing around with the risk to end up in problem with the OS far worse then Firefox repainting. :-) I'll try to find the time to set up a spare machine (or a VM or the same computer with another HD) to make some experiments.
Reporter | ||
Comment 38•8 years ago
|
||
If can help I've tried to disable GPU acceleration this way PIPELIGHT_GPUACCELERATION=0 ./firefox and no difference from the opposite explicit PIPELIGHT_GPUACCELERATION=1 ./firefox
Comment 39•8 years ago
|
||
Discussed with Karl. We agreed that since bug 1287463 does not actually require the use of a separate display connection to solve the error situation with create XShm images, that the right move for now is to go back to using the single display. The separate display is only really needed for some GL context issues, but not for XShm. This should resolve it for 52, and we'll need to uplift to 51.
Comment 40•8 years ago
|
||
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/20ff6628ea8b Move back to using window display for basic composition paths. r=lsalzman
Reporter | ||
Comment 42•8 years ago
|
||
I've tried FF Dev edition on a VM (VirtualBox) on the same computer and I've got the same problem in there, so I can now try anything without messing my main system.
Reporter | ||
Comment 43•8 years ago
|
||
Marco+compositing = OK Marco+compton = OK Metacity = BAD Metacity+compositing = OK Metacity+compton = OK Compitz with defaults (MINT 18 Mate) = OK Compitz with composite+openGL = OK Compitz with no composite/openGL = BAD (Composite and OpenGL go together: I can't turn on/off openGL alone)
Comment 44•8 years ago
|
||
Comment on attachment 8802511 [details] [diff] [review] Revert to using the window X display for basic composition paths. Approval Request Comment [Feature/regressing bug #]: Bug 1287463 [User impact if declined]: Browser window on Linux will not repaint properly after window manager interactions like workspace switches, window interactions, etc. Since the change in bug 1287463 turned out to be unnecessary, and just introduces a regression without actually contributing the problem it was expected to solve, there's no strong evidence for keeping it around. [Describe test coverage new/current, TreeHerder]: Pretty much everything since this patch is regarding blitting to the browser window, so if it was broken, we'd notice pretty quick. [Risks and why]: This should be very safe, since this just reverts us to how we previously behaved with respect to expose event handling for Linux up to and including 49. Kats already did a similar backout for 50 as this patch does, so we've already tested the backout with beta, and it seems to have fixed the issue without introducing new problems. Reporter also verified with a test build that this fixes his issue. [String/UUID change made/needed]: None
Flags: needinfo?(riksoft)
Attachment #8802511 -
Flags: approval-mozilla-aurora?
Comment 45•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/20ff6628ea8b
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment 46•8 years ago
|
||
Seems like this regressed tpaint quite substantially on linux - https://treeherder.mozilla.org/perf.html#/graphs?series=%5Bmozilla-inbound,b4b21ba1c506bb8fd6161e7bd2eda6e37dbe4326,1,1%5D&series=%5Bmozilla-inbound,e7754f5593188de8aaa57a1a85c03be0896bae04,1,1%5D&series=%5Bmozilla-inbound,3e3d447aabf05aef83bd85a03525905aa238af22,1,1%5D&series=%5Bmozilla-inbound,79fb157eb94529568f02bd94de4a1bcb707d7c62,1,1%5D 25% is something that should not land unnoticed?
Updated•8 years ago
|
Flags: needinfo?(lsalzman)
Comment 47•8 years ago
|
||
In that particular case, the talos numbers are suspect - as in, this bug casts doubt on whether proper painting was ever happening at all or was improperly synchronized with the patch before it got backed out. And even then, those results come at too great a cost (i.e. this bug). Whatever talos regressions arise, I am willing to accept here.
Flags: needinfo?(lsalzman)
Comment 48•8 years ago
|
||
Comment on attachment 8802511 [details] [diff] [review] Revert to using the window X display for basic composition paths. Fix a regression. Take it in 51 aurora.
Attachment #8802511 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 49•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/b3a503af6c86
Comment 50•7 years ago
|
||
On a virtual box, I installed Linux Mint 18. Verified on this OS and bug is not reproducible for me on Latest Nightly 52.0a1 nor on the latests Aurora 51.0a2 or Beta 50.0b11. Problem is that on this virtual os, I could not reproduce the bug on Firefox version that Rik reported it: Firefox Develper Edition 50.0a2 (2016-09-19) Rik, when have time, could you please try this issue and let us know if it is still reproducible on latest Firefox version on your side?
Flags: needinfo?(riksoft)
Comment 51•7 years ago
|
||
this issue is only reproduceable on with a non-compositing window manager - otherwise the window manager handles exposure or the application.
Reporter | ||
Comment 52•7 years ago
|
||
The bug has been solved and I reckon it's already distributed through the alfa channel because my 51.0a2 (2016-11-14) is now working fine.
Comment 53•7 years ago
|
||
Based on comment 52 and comment 50, mark this bug Verified as Fixed.
Status: RESOLVED → VERIFIED
Flags: needinfo?(riksoft)
You need to log in
before you can comment on or make changes to this bug.
Description
•