Re: 3d favicons

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).

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.

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


Bye,
Cecile

2018-08-20 19:06 GMT+02:00 Florian Bösch <pyalot@gmail.com>:

>
>> But if you mean that a client-side application like in the link can't
>> render a 3d icon,
>> there is no reason the same "use canvas to render arbitrary contents for
>> the favicon"
>> can't be used with a canvas rendering a 3d object as well:
>>  - First, read the url to the 3d model from the link tag
>>  - Then, load the model in three.js (for example)
>>  - Then on render, convert the canvas to base64 and put the image in the
>> favicon
>>
>> It could even render shaders & postprocessing fine because it just
>> screenshots the canvas to a base64 png.
>>
>
> This relies on a readback which will induce a pipeline stall, because in
> order to perform the readback the GPU has to block the call in client space
> until all pending operations have completed, thereby blocking all script
> execution in JS until the GPU is no longer busy, it's very bad for
> performance, especially if the icon isn't the only thing you're rendering.
>