Re: 3d favicons

On Mon, Aug 20, 2018 at 7:47 PM Cecile Muller <contact@wildpeaks.fr> wrote:

> Whether the favicon link is a 2D image or a 3D model, they both end up
> having to be downloaded (unless they're embedded as base64).
>

If you assume the browser has to know how intrinsically how to render a 3D
model (rather then the site developer supplying code that does it), it
means you're going to have a vastly restricted palette of possibilities as
compared to WebGL or Canvas2D.


> And if you worry about the download & parsing of the model file blocking
> the main thread, that step can be done in a webworker instead.
>
And as for the "3D rendered to a 2D image", you could run it using
> requestAnimationFrame like regular WebGL.
>

It's not a question of a webworker or RAF. In order to base64 encode a
canvas you have to perform a readPixels. This is what's known as a
"readback" and it will stall the GPU process until all pending commands (on
the GPU) for that context have finished. It will also stall/block the JS
main thread (or the webworker) because no data can be delivered to these
processes until data is actually available, which won't be available unless
the GPU finishes. It's a synchronizing command, it synchronizes the GPU and
all processes involved in the CPU side of the execution. Since you can not
send new commands to the GPU to work on while your JS main thread is
blocked, both the GPU and the CPU will be "idle", wasting wall-clock time
waiting for things to happen. That's why it's bad for performance (because
you're not using it), and if you tried to use it, you can't, because
wall-clock idle time has passed and you can't wind back time and get it
back.

3D instead of 2D wouldn't add limitations that aren't already in the
> Defender example too.
>

Any kind of interpretation is always a limitation compared to something
being programmable.