For our simple, BasicLayers (readback) implementation of CanvasLayer, AFAICT from poking through docs there's no real difference between rendering to pixmap rather than a pbuffer with GLX. (Vlad, is that right?) The difference comes from GLX_EXT_texture_from_pixmap, which enables what one would guess. I couldn't find anything similar to ARB_render_texture for GLX, and indeed found a site that claimed that binding pbuffers to textures isn't supported by GLX. My relatively modern card (Geforce GT 220) doesn't appear to support any extensions that sound close. (Vlad, is that right? ;) ) So, this bug just covers the migration from pbuffer->pixmap in the GLX code. Luckily this is all contained within GLContextProviderGLX.

Comment on attachment 451507 [details] [diff] [review] Render WebGL canvases into GLXPixmaps rather than GLXPbuffers (In reply to comment #0) > For our simple, BasicLayers (readback) implementation of CanvasLayer, AFAICT > from poking through docs there's no real difference between rendering to pixmap > rather than a pbuffer with GLX. (Vlad, is that right?) pixmap render targets tend to be horribly unaccelerated, at least from my understanding. > The difference comes from GLX_EXT_texture_from_pixmap, which enables what one > would guess. I couldn't find anything similar to ARB_render_texture for GLX, > and indeed found a site that claimed that binding pbuffers to textures isn't > supported by GLX. My relatively modern card (Geforce GT 220) doesn't appear to > support any extensions that sound close. (Vlad, is that right? ;) ) Right; on Linux, the X/GLX folks have largely decided that FBOs are the way to go for rendering to something that you want to use as a texture. This is fine, except it ignores an important use case of actually /wanting/ a separate GL context with no shared resources, since your only options are to share no GL resources between contexts or share them all. If you share them all, then you have to be extra careful about resource deletion, since you can't count on the context to clean up. The FBO use case is when a single app wants to do rendering to something that it wants to use as a texture; for that use case, multiple contexts are very undesirable because of the need to switch contexts... but that's not directly valid when you have what are essentially separate "apps", one of which wants to produce something that can be consumed by another. > So, this bug just covers the migration from pbuffer->pixmap in the GLX code. > Luckily this is all contained within GLContextProviderGLX. The code is fine, I'm just not sure if we want to do it; switching to FBOs would get you the performance that you expect, though we would have to do more work on the WebGL side. However, we'll need to do that anyway, and to do that we still need to create a context for *something*, and that something is going to have to end up being a Pixmap because pbuffers aren't commonly available. So maybe we can just go ahead with this; it's not going to make anything significantly worse, though I suspect WebGL will become much slower temporarily on some configurations.

This doesn't create a pixmap with alpha, as best I can tell -- no go without that.

This pirates code from mattwoodrow's patch in bug 565833 to choose a RGBA visual for GLX. (This was working on my machine with the system-default RGB visual, even with texturing in bug 572300. Still unclear why both would work; the former likely because of readback.)

Use the GLContext::Format to be certain that we use the right Visual for the pixmap.

Updated wrt bug 572939, which will land before this.

Comment on attachment 452885 [details] [diff] [review] Render WebGL canvases into GLXPixmaps rather than GLXPbuffers, v4 So I'm minusing this not because it's not correct, but because I'm about to switch over how WebGL (and other) stuff renders anyway -- pbuffers won't be used, we'll just use FBOs directly, sharing with a global context. So there's no need for this. I do however need the GLX context provider's CreateForNativePixmapSurface implemented, but I think that's already done in a bug somewhere (or if not, I'll just write it).

Blocking this on the switch. With bug 573889, we could remove CreateForNativePixmapSurface() in favor of the new CreateTextureImage() API, but we can discuss that when 573889 is ready.

Please choose wisely how you will render. If you choose to render using old extensions (such as pbuffers + WGL_ARB_render_texture) you could end up with no support for meany platforms. AFAIK currently Mindefiled windows version requires WGL_ARB_render_texture which is not implemented on Intel platforms(and I think it won't be implemented, becouse it is very old extension). While Intel has ~50% of graphics market share, this is a serious issue. Competition (Chrome) shows that it is possible to do it other (working) way.

AFAICT bug 575469 incorporated or independently subsumed the meat of this patch, closing as DUP.