This is becoming the default in several linux distributions and it makes WebKitGTK+ unusable in accelerated compositing mode, which is now always enabled because since we switched to use the threaded compositor. The problem seems to be an optimization of the intel driver for windows that are offscreen, and our redirected window is always positioned at ScreenWidth + 1, 0.
Created attachment 285205 [details] Patch
I was tempted to r+ but it looks like this is an undesirable side effect, so I'd prefer not to rely on that. From the freedesktop bug: "Weird, not sure why that avoids the problem; maybe there's an off-by-one bug somewhere which causes the window to be incorrectly considered on-screen. I wouldn't recommend relying on that. Also, again I'm not sure that negative coordinates can never be visible." Also "Assuming a window is really the only possibility, (why) can't it set the swap interval to 0 via one of the GLX extensions for this, to prevent SwapBuffers operations from getting throttled?" Can't we do this instead?
(In reply to comment #2) > I was tempted to r+ but it looks like this is an undesirable side effect, so > I'd prefer not to rely on that. From the freedesktop bug: > > "Weird, not sure why that avoids the problem; maybe there's an off-by-one > bug somewhere which causes the window to be incorrectly considered > on-screen. I wouldn't recommend relying on that. Also, again I'm not sure > that negative coordinates can never be visible." Yes, but he also said that using WidthOfScreen is bad in any case, so if the patch fixes that and works as a workaround, we could land it in any case and then continue working a better solution, but with a workaround to make WebKitGTK+ usable again. > Also > > "Assuming a window is really the only possibility, (why) can't it set the > swap interval to 0 via one of the GLX extensions for this, to prevent > SwapBuffers operations from getting throttled?" > > Can't we do this instead? I guess, I'm not a graphics expert, and I don't even know if we really need to use a window or not. I'll take a look at the swap interval thing in any case.
(In reply to comment #3) > Yes, but he also said that using WidthOfScreen is bad in any case True. r=me on that basis, but I recommend giving the upstream bug a couple days to settle before committing, now that the Xorg folks are actively looking into the issue. We also should have an answer to their question as to why we use an offscreen window instead of a pixmap, which is clearly their recommendation.
CCing folks who might possibly have an answer to the question in comment #4.
(In reply to comment #2) > I was tempted to r+ but it looks like this is an undesirable side effect, so > I'd prefer not to rely on that. My main concern is that it might be a bug that the negative offset works to avoid throttling.
(In reply to comment #6) > (In reply to comment #2) > > I was tempted to r+ but it looks like this is an undesirable side effect, so > > I'd prefer not to rely on that. > > My main concern is that it might be a bug that the negative offset works to > avoid throttling. Right, that's why I don't consider it a fix, if that's actually a bug and is fixed eventually the performance will be bad again, but I'm pretty sure we will not be the only ones affected like now, because most of the code that creates an offscreen window use negative coords, either -1, -1 or -100, -100.
Committed r204250: <http://trac.webkit.org/changeset/204250>
I experience bad performance with accelerated compositing mode on using WebkitGTK+ 2.22.5 on Fedora 29 with Intel Iris 540 (Skylake mobile) graphics. Turning it off makes pretty much everything faster, but particularly Facebook, which is nearly unusable with accelerated compositing on. Also, when playing videos or scrolling through a site like Facebook, the laptop becomes hot and the fan goes full blast, which does not happen with accelerated compositing off. Would this bug be the issue I'm experiencing, or should I file a new bug about this?