Stage3D

[cwe...@cimaron.net]

"In order to emulate events on the original WebGL canvas, you may put
a transparent DIV on top of flash player with a higher z-index and use
that div to communicate events between flash player and javascript. In
other words, when a developer wants to add a mouse down or mouse move
events, adding event actions must be directed to this transparent DIV
under the hood. The events will be passed to flash player as they
fired on this DIV again under the hood." (http://code.google.com/p/
cwebgl/issues/detail?id=4#c6)

That's exactly right. There are a few other caveats, however. First is
that a native WebGL context can be generated and used immediately.
Flash, however, needs time to load. So, client code will need to be
changed so that it doesn't depend on the context being ready
immediately. We need to provide a way to pass a callback. Something
like:

function WebGLStart() {
//draw commands
}
window.onload = function() {
gl = canvas.getContext('webgl');
gl.onReady(WebGLStart);
}

Secondly, since Stage3D is not very GL-like, it's going to need to
depend on the software GL layer more than I had anticipated, which is
going to require restructuring by removing the rendering layer from
the GL layer completely.

Finally, compatibility is probably not going to be 100%. An example is
the fact that AGAL does not seem to support any output from the
fragment shaders other than color. This means no writing depth value,
for example. This probably isn't a deal-breaker for the majority of
cases, but it is something to keep in mind.

[Bora]

On Jan 17, 5:56 pm, cwe...@cimaron.net wrote:
> "In order to emulate events on the original WebGL canvas, you may put
> a transparent DIV on top of flash player with a higher z-index and use
> that div to communicate events between flash player and javascript. In
> other words, when a developer wants to add a mouse down or mouse move
> events, adding event actions must be directed to this transparent DIV
> under the hood. The events will be passed to flash player as they
> fired on this DIV again under the hood." (http://code.google.com/p/
> cwebgl/issues/detail?id=4#c6)
>
> That's exactly right. There are a few other caveats, however. First is
> that a native WebGL context can be generated and used immediately.
> Flash, however, needs time to load. So, client code will need to be
> changed so that it doesn't depend on the context being ready
> immediately. We need to provide a way to pass a callback. Something
> like:

You can overcome the delay by providing a webgl context detection
mechanism which would be mandatory to call at the beginning of the
webgl code. After the initialization developer's main webgl code
method
can be called in a delegation alike model. Since cwebgl is a emulated
platform, I believe a detection mechanism would make sense for
everybody.
All the webgl code out there has a detection code at the beginning
anyways.

>
> function WebGLStart() {
>   //draw commands}
>
> window.onload = function() {
>   gl = canvas.getContext('webgl');
>   gl.onReady(WebGLStart);
>
> }
>
> Secondly, since Stage3D is not very GL-like, it's going to need to
> depend on the software GL layer more than I had anticipated, which is
> going to require restructuring by removing the rendering layer from
> the GL layer completely.
>
> Finally, compatibility is probably not going to be 100%. An example is
> the fact that AGAL does not seem to support any output from the
> fragment shaders other than color. This means no writing depth value,
> for example. This probably isn't a deal-breaker for the majority of
> cases, but it is something to keep in mind.

These are all fine points. However bear in mind that, no one is going
to ask for 100% compatibility from an emulation. On the other hand,
it would make sense to separate stage3D and canvas based
distributions. The code base may get quite large if both are included
together. A lazy loading mechanism depending on the environment
detected may be desirable.

[cwe...@cimaron.net]

Took a while, but I've finally finished rewriting the driver system so
that we can have swappable drivers.

At this point, there's going to be 3 drivers: software, flash, and
native WebGL (for debugging the non-rendering portions of the
library). The flash driver has been started, but it doesn't do much
other than clear the screen.

As discussed above, there will be changes required in client code to
support the Flash driver. Something like:

//native=false: use the cwebgl library instead of the native library
gl.getContext('webgl', {native:false});
//add gl context ready handler
gl.onReady(WebGLRun);

Though, since the canvas based contexts will be ready immediately, it
will still work without adding the onReady handler.