[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Issues with sharing resources across contexts
On Fri, Aug 24, 2012 at 11:48 PM, Kenneth Russell <email@example.com> wrote:
is no way to use HTMLCanvasElements, or any other DOM element, from a
1) It isn't compatible with using WebGL in a worker. At present there
worker, and it seems that enabling that is a very long road to go down
with the HTML5 standards groups.
I don't think it does have to solve it. Being able to address different addressable front-surfaces and being able to render to front surfaces from workers and being able to share resources between workers and main thread are actually 3 separate problems with almost no overlap. Main thread and workers would benefit from being able to address multiple front surfaces. Regardless of addressed front surface, workers would benefit from being able to use front surfaces at all. And regardless of workers capability to address front surfaces, or the amount of surfaces addressable, resource sharing would be useful when workers or main threads interact.
2) As Florian points out, it only supports use of the canvas as an
output surface. I think there are likely to be a lot of use cases
where it's desirable to use the rendered output as a texture for
another rendering stage.
That's true, but I also said it's not a big deal long as we don't have to
1) deal with some complex/convoluted locking/synchronization/semaphoring/aquire/release/pray scheme. Not that this isn't required, it is, for other usecases, it just isn't required for the need to address multiple front surfaces.
2) not have to multiplex resource buildup across multiple canvases (as we would currently do)
3) or perform readbacks to blit to canvas 2d (as we also currently do)
3) It doesn't address all of the use cases that share groups do, and
if share groups were introduced later, they might make this API
Like I said, I see front surface addressability and resource sharing as two completely different and fundamentally orthogonal aspects of rendering. One does not preclude the other, and a design shouldn't imply that imo.