Re: 3d favicons

On Mon, Aug 20, 2018 at 7:39 AM John D. Gwinner <john@gwinner.org> wrote:

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

The current favicon syntax already supports this so we should build upon
that.


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

No really, Favicons won't stop loading when the author hits the stop
button.
I'm also unsure if the browser will show a "loading" state if the document
is ready but the favicon is still in progress.

I strongly believe that we should just add minimum functionality on what is
already there and not add new behavior.


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

+1 to this!


> ------------------------------
> *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>:
>
> Note that neither vrml nor gltf will cover use-cases like this:
> http://www.p01.org/defender_of_the_favicon/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.p01.org_defender-5Fof-5Fthe-5Ffavicon_&d=DwMF-g&c=0ia8zh_eZtQM1JEjWgVLZg&r=jahSgznxrAL5kPgsRvs7bhKUEd9M5X0d-NE2WJg7VT0&m=nveBCB_rhzwcOsmNH7-vRLb_UZQHzNiSX1xXoy2XzPU&s=cjZvvvGPOG5Qb1dAnZVyj-4o7Ot8lIQ7TKtu4VkZK3Q&e=>
>
> 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).
>
>
>
>