Re: 3d favicons

If you mean that browsers currently don't understand 3d file formats
natively,
having the fallback first in the list should be enough to let non-3d
browsers pick the png initially,
then it could be augmented by script.


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.


As for choosing a 3D model that isn't heavy for end users, that's up to the
content authors ?
(which is why I was suggesting something like "img srcset" in an earlier
email,
for authors to hint which models would fit best what kind of conditions).

But there is no reason the script that loads the model can't also check the
number of polygons,
or what kind of shader it uses, or even replace the shader by a basic one
if you really want to.


Bye,
Cecile

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

> Note that neither vrml nor gltf will cover use-cases like this:
> http://www.p01.org/defender_of_the_favicon/
>
> Supposing you'd want to support shaders (that gltf has support for), it's
> trivial to bring any machine to its knees with either a massive amount of
> triangles, a massive amount of overdraw (a few thousand triangles
> z-fighting) or some massive computation in a shader (just a few lines of
> loops).
>
> On Mon, Aug 20, 2018 at 11:37 AM Cecile Muller <contact@wildpeaks.fr>
> wrote:
>
>> Using a media query rule, similar to stylesheets targeting features like
>> light intensity, example:
>>
>> <link "favicon.gltf" rel="icon" media="3d">
>>
>> <link "favicon.gltf" rel=" icon " media="3d and (min-power: 50%)">
>>
>> <link "fallback.png" rel="icon">
>>
>>
>> Similarly, having multiple link would let the browser choose which
>> formats it prefers:
>>
>> <link "favicon.gltf" rel="icon" media="3d">
>> <link "favicon.wrl" rel="icon" media="3d">
>>
>>
>> Bye,
>> Cecile
>>
>> 2018-08-20 9:27 GMT+02:00 Kip Gilbert <kgilbert@mozilla.com>:
>>
>>> Just to add a possibly crazy idea...
>>>
>>> Animated gif..  Stack frames on z-axis to generate voxels.  Transparent
>>> pixels generate no voxel.  Ideal for < 50x50x50 cubes...
>>>
>>> Real question..  Should we allow multiple formats — and if so, define
>>> how we fall back to simpler formats for low power / memory devices?
>>>
>>> Cheers,
>>>
>>>   Kearwood “Kip” Gilbert
>>>
>>>
>>> On Aug 19, 2018, at 8:25 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>>
>>> On Mon, Aug 20, 2018 at 5:35 AM Rik Cabanier <rcabanier@magicleap.com>
>>> wrote:
>>>
>>>> On Sun, Aug 19, 2018 at 9:17 AM Florian Bösch <pyalot@gmail.com> wrote:
>>>>
>>>>> I'd favor making it possible to target the favicon with a canvas
>>>>> directly. As in:
>>>>>
>>>>>> <link id="icon" rel="icon" type="image/png" href="..."
>>>>>> animated="True">
>>>>>> <script>
>>>>>>   window.onload = function(){
>>>>>>      var icon = document.getElementById('icon');
>>>>>>      var ctx = icon.getContext('3d'); // or 2D
>>>>>>      ...
>>>>>>   }
>>>>>>  </script>
>>>>>
>>>>>
>>>>> That way you can put in anything you want (even video) at any speed
>>>>> you want (realtime if so desired, or slower), with any technique you want
>>>>> (2D canvas or 3D canvas).
>>>>>
>>>> How would you make it 3d? It seems that would require script to run...
>>>>
>>>
>>> Correct, a script would need to run.
>>>
>>>
>>>> I don't think this approach will work though as the favicon is not part
>>>> of the DOM and can be rendered when the document isn't even loaded (ie for
>>>> bookmarks). I suspect such a change will be hard to specify and implement
>>>>
>>>
>>> It's my impression that the majority use-case for an animated favicon is
>>> in the tab when the web page is open (running a script also allows the page
>>> to interact live with the icon, so that's an additional benefit). For
>>> use-cases which cannot execute scripts (like bookmarks) they'd use the
>>> fallback image provided.
>>>
>>> I suppose you'd object to running a script everywhere a favicon can be
>>> displayed mainly on performance concerns (who wants to run like say 200
>>> scripts on a bookmark overview page or somesuch?). But if that is the main
>>> objection, then animated 3D favicons everywhere are out no matter how you
>>> do them. Unlike static (or even moving) images, which have well defined
>>> performance characteristics, 3D content can easily be made to consume any
>>> amount of computing resource (for instance make a favicon with 10 million
>>> triangles).
>>>
>>>
>>