[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Public WebGL] Moving WEBGL_shared_resources to rejected status

You can expect drawing a WebGL canvas to a 2D canvas to do a GPU copy. It’s not particularly slow, at least on desktop GPUs with plenty of bandwidth. And in the hopefully-not-too-distant future, transferToImageBitmap is intended to enable a similar operation without any copying at all.


From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Florian Bösch
Sent: lauantai 28. huhtikuuta 2018 22.24
To: Ken Russell <kbr@google.com>
Cc: public <public_webgl@khronos.org>
Subject: Re: [Public WebGL] Moving WEBGL_shared_resources to rejected status


On Sat, Apr 28, 2018 at 4:50 AM, Ken Russell <kbr@google.com> wrote:

The issue is that on OpenGL ES the only guaranteed way to publish changes from one context to another is by calling glFinish, which is prohibitively expensive.


That's the first I've heard about that, I'm not sure that's how it was meant. Regardless, sharing resources would happen between contexts living within one live page. All WebGL contexts there are virtual, even on platforms that do not have a dedicated GPU process. What the actual context can share or not is of no relevance, because you just overlay whatever sharing semantic you want since you all operate within the same actual context.



There are other ways on the web platform to draw to multiple canvases with one WebGL context.


As of yet there are none for WebGL.


Multiple visible canvases can be created with the '2d' rendering context, and an invisible WebGL-rendered canvas drawn to them using CanvasRenderingContext2D.drawImage.


Afaik this would be pretty slow as it'll perform a readback to obtain pixel data to put into the 2D canvas buffer does it not?