[Bug 85064] modesetting driver plus DRI3 causes extremely slow scrolling with WebKitGTK+ in accelerated compositing mode

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85064

--- Comment #42 from Carlos Garcia Campos <carlosgc at gnome.org> ---
(In reply to Michel Dänzer from comment #41)
> (In reply to Carlos Garcia Campos from comment #40)
> > Yes, this is because we use the screen width + 1 to position our window
> > offscreen:
> > 
> > WidthOfScreen(screen) + 1, 0, 1, 1,
> 
> FWIW, WidthOfScreen is bad anyway because that's just how wide the screen
> happened to be when the X11 display connection was established. The screen
> can be widened after that via the RandR extension, in which case the window
> would become visible.

So, I guess using -1, -1 is still a good idea even if it fixes the problem by
casuality.

> > and it turns out that simply using -1, -1 as coordinates fixes the problem.
> 
> 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.

Not sure it's off by one, using -100, -100 also works. Yes, that's more a
workaround to make WebKitGTK+ usable again while we find the right solution.

> 
> So, why does this code use a window instead of a pixmap?

I don't really know it, I'm not a graphics expert.

> 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?

I tried using glXSwapIntervalSGI(0); after glXMakeCurrent but didn't help.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160803/065c8203/attachment.html>