On Mon, Jan 9, 2012 at 5:52 PM, Gregg Tavares (wrk) <firstname.lastname@example.org>
I'm not sure I follow here.
different hardware capabilites: canvas 2d (size limits), images(size limits, different format support), memory(a phone has less than my desktop), touch vs mouse, tiny screen vs large, tilt vs no tilt, ability to create window (popup) vs no such ability (phones).
We were talking about threading.Â An example of code which can behave nondeterministically in current APIs is localStorage.Â The following code may behave unexpectedly:
if(localStorage.a != localStorage.a)
ÂÂÂ throw "fail";
If another thread modifies localStorage.a between the two accesses, the exception is thrown.Â This is considered a major design flaw in the Web Storage API.Â Exposing shared resources would have similar effects.Â I'm not strongly opposed to it myself, but others will be, because it goes against the design of Web Workers.
See 1.7.1 in http://www.whatwg.org/specs/web-apps/current-work/#design-notes
I don't personally feel at all strongly about this design principle, but others do; the farther WebGL deviates from the principles used by other APIs, the more of an "outsider" WebGL will be, rather than an intrinsic part of the platform.Â I just want to make sure you're aware of it.
Another thing to note is that workers are designed so
that they can be implemented either with a threading model or a process
model; the inter-thread boundary is defined in a way that allows
either.Â Shared WebGL resources would probably only work with
the threading model, not the process model.Â I don't know if any Web Workers implementations actually use the process model, but it's something to keep in mind.Â At minimum, it suggests that shared resources should always be an optional feature, not promoted to a core feature, to avoid creating a design conflict.
To get speed benefits you need to be able to transfer ownership efficiently and there's no easy way to do that with processes AFAIK. So, the idea of using processes for workers has pretty much been abandoned.
Speed benefits are far from the only category of use cases for workers (in my opinion, they're among the less important).
A prerequisite would be having WebGL available to workers in the first place.Â There are big hurdles to that (which I'm sure you're well aware of--the DOM thread-safety issue).Â I do hope this happens eventually.
I don't see any issues here. The definition of WebGL is that any call can fail at any time. Adding shared resources and WebWorkers none of that changes. The sharing semantics seem pretty well defined. I'm probably missing something but I'm not seeing a problem right now.
To expose WebGL to workers, you need access to part of the DOM API, in particular HTMLImageElement, or you can't (sanely) load textures.Â The DOM isn't exposed to workers because DOM implementations aren't threadsafe.Â You'll need to convince vendors to fix this for at least a limited subset of the DOM to make WebGL usable, before it makes sense to expose it.Â Again, I do want to see this happen.
On Mon, Jan 9, 2012 at 5:36 PM, Gregg Tavares (wrk) <email@example.com>
if (ctx1.group == ctx2.group) Â
Â Â// they are sharing resources
Such a group is basically needed under the hood anyway
That information might be stored at a lower level, though, if it's
implemented with an API like wglCreateContextAttribsARB.Â It's not a big deal
to track it separately, of course.