Re: 3d favicons

I really like the fallback / multiple link content. Browsers/other software can pick what they can render (possibly with user feedback, i.e. "Disable any 3D favorite worlds" etc.


It really is up to content authors. Any author can bring a browser to it's knees if they want. This is no different.


After having said that, browsers can also look at frame rate, and decide to fall back on their own if necessary. (Could be a minimum frame rate setting as well).


That defender clone is great.


But then again, as I type this, I'm on Playa at "That thing in the dust" so I'm a "Radical Self Expression" guy and feel it's mostly up to the content authors. Let's give them a standardized way to express themselves, to make browser adoption standardized as well. I don't want to return to the "Best viewed by" web.


== John ==

________________________________
From: Cecile Muller <contact@wildpeaks.fr>
Sent: Monday, August 20, 2018 7:28:04 AM
To: public-immersive-web@w3.org
Subject: 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<mailto: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<mailto: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<mailto: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<mailto:pyalot@gmail.com>> wrote:

On Mon, Aug 20, 2018 at 5:35 AM Rik Cabanier <rcabanier@magicleap.com<mailto:rcabanier@magicleap.com>> wrote:
On Sun, Aug 19, 2018 at 9:17 AM Florian Bösch <pyalot@gmail.com<mailto: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).