Regarding the three steps of offscreen rendering:<div><br></div><div>1. Draw stuff</div><div>2. Ship pixels to main thread</div><div>3. Draw them on the screen.</div><div><br></div><div>How would you do #2 efficiently? If you used toDataUr<i>l</i>(), then you have to encode a png on one side and then decode the png on the main thread. I think we might want to add some sort of API for blitting directly from an offscreen canvas to an onscreen one. Perhaps via a canvas ID.</div>

<div><br></div><div>Andrew</div><div><br><br><div class="gmail_quote">On Wed, Feb 24, 2010 at 6:12 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5"><br>
On Feb 24, 2010, at 1:35 AM, Jonas Sicking wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak <<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote:<br>
<br>
On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote:<br>
<br>
On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> wrote:<br>
<br>
- Raytracing a complex scene at high resolution.<br>
<br>
- Drawing a highly zoomed in high resolution portion of the Mandelbrot set.<br>
<br>
To be fair though, you could compute the pixels for those with just math,<br>
<br>
there is no need to have a graphics context type abstraction.<br>
<br>
<a href="http://people.mozilla.com/~sicking/webgl/ray.html" target="_blank">http://people.mozilla.com/~sicking/webgl/ray.html</a><br>
<br>
I did not think it was possible to write a proper raytracer for arbitrary<br>
content all as a shader program, but I do not know enough about 3D graphics<br>
to know if that demo is correct or if that is possible in general. Point<br>
conceded though.<br>
</blockquote>
<br>
The big thing that GLSL is lacking is a stack, making it impossible to<br>
recurse properly. This isn't a huge problem to work around, though can<br>
result in ugly code. Especially if you want to support transparent<br>
objects, in which case you'll essentially have to unroll recursion<br>
manually by copying code.<br>
<br>
This of course makes it impossible to recurse to arbitrary levels,<br>
though that is something you generally don't want to do anyway in a<br>
ray tracer since it costs a lot of CPU (or in this case GPU) cycles<br>
for very little visual gain.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://people.mozilla.com/~sicking/webgl/juliaanim.html" target="_blank">http://people.mozilla.com/~sicking/webgl/juliaanim.html</a><br>
<a href="http://people.mozilla.com/~sicking/webgl/mandjulia.html" target="_blank">http://people.mozilla.com/~sicking/webgl/mandjulia.html</a><br>
<br>
Neither of examples you posted seems to have the ability to zoom in, so I<br>
don't think they show anything about doing this to extremely high accuracy.<br>
But I see your point that much of this particular computation can be done on<br>
the GPU, up to probably quite high limits. Replace this example with your<br>
choice of non-data-parallel computation.<br>
<br>
Following the links, this demo does do zoom, but it will go all jaggy past a<br>
certain zoom level, presumably due to limitations of GLSL.<br>
<a href="http://learningwebgl.com/lessons/example01/" target="_blank">http://learningwebgl.com/lessons/example01/</a>?<br>
</blockquote>
<br>
Indeed. Zooming is no problem at all and doesn't require any heavier<br>
math than what is done in my demo.<br>
</blockquote>
<br></div></div>
Zooming does require more iterations to get an accurate edge, and WebGL has to limit your loop cycles at some point to prevent locking up the GPU. But of course once you are at that level it would be pretty darn slow on a CPU. I have seen mandelbrot demos that allow essentially arbitrary zoom (or at least, the limit would be the size of your RAM, not the size of a float).<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I experimented with allowing the<br>
animations to be stopped at arbitrary points and then allowing<br>
zooming. However it required more UI work than I was interested in<br>
doing at the time.<br>
<br>
The reason the demo goes jaggy after a while is due to limitations in<br>
IEEE 754 floats.<br>
</blockquote>
<br></div>
On the CPU you could go past that if you cared to by coding your own high precision math. But it would be quite slow.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But I should clarify that my point wasn't that WebGL makes<br>
off-main-thread graphics processing unneeded. I just thought it was<br>
funny that the two examples you brought up were exactly the things<br>
that I had experimented with. Although I wouldn't be surprised if a<br>
lot of the image processing effects that people want to do can be<br>
written as shader programs. Would definitely be interesting to know if<br>
WebGL could be supported on workers.<br>
</blockquote>
<br></div>
I'm very much interested in the possibility of WebGL on Workers, which is why I suggested, when reviewing early drafts of this proposal, that the object should be an OffscreenCanvas rather than a special Worker-only version of a 2d context (with implied built-in buffer). This makes it possible to extend it to include WebGL.<br>


<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br></div>