Stop allocating GpuMemoryBuffer client-side in WebGL's DrawingBuffer |
|||
Issue descriptionQuoting piman@ from my CL: "In the case where we don't need RGB emulation, we can use the non-GMB CreateSharedImage path (with the gpu::SHARED_IMAGE_USAGE_SCANOUT) which is more efficient, as it allocates the GMB on the service side, without requiring synchronous round-trips to the browser. For the RGB emulation case, we still need the GMB as that's how we can create 2 textures with different internalformats, but we can tackle that separately."
,
Dec 3
I guess at the very least we can do it for cases that RGB emulation is not required, but that would increase the complexity in DrawingBuffer as we will have to maintain two different code paths. However, the improved efficiency could be worth it. What do you think?
,
Dec 3
We can probably move a subset of the RGB emulation (just the part that handles BlitFramebuffer which is what requires another texture) to the service side and entirely eliminate the need for client-side GMBs, while leaving the preserve-alpha logic client side (for now).
,
Dec 3
,
Dec 11
|
|||
►
Sign in to add a comment |
|||
Comment 1 by kbr@chromium.org
, Dec 3