Comment 59 for bug 1615871

(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.