> 2. Investigate if there's some way to hack around it (using RGB pixmaps > but somehow storing and reconstructing the alpha channel maybe?)
This sounds pretty workable to me. We can send alpha as the R channel of a second pixmap/texture and the compositor can extract it within a fragment shader. > 3. Shared memory with texture upload on the compositor side. > > #3 is guaranteed to work, but has bad performance implications (though > no worse than the browsers of today). If we're rendering on the CPU anyway, what's the performance hit of compositor upload? Is the issue that we'd like to upload in parallel with compositor work (and thus avoid jank)? I'm one of the people who can't use RGBA pixmaps, on Linux with NVIDIA binary drivers (which I naively thought were feature-complete). When I switch to RGB pixmaps (patching rust-layers thus: https://gist.github.com/kmcallister/7206061), I can run servo with CPU rendering (./servo -c) but with GPU rendering I get X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 135 (GLX) Minor opcode of failed request: 22 (X_GLXCreatePixmap) Serial number of failed request: 141 Current serial number in output stream: 142 I'm not sure why this is happening but I didn't have much time to dig into it yet. keegan _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
