Re: 3d favicons

There is already a kind of "best viewed with" now: high resolution images
look best on high dpi screens, a given 3d model has more fps and can use
more complex shaders on higher end graphic cards, more content can be shown
(or with different layouts) on bigger screens, mobiles can be
location-aware, and different interactions based on the input devices, etc.

The difference from the "best viewed with IE6" era is that content authors
got into the habit of adapting to the constraints & features of the browser
(e.g. Media Queries) instead of optimizing only for a specific browser.

So it's OK if something doesn't look exactly the same in all conditions.


Bye,
Cecile

2018-08-20 16:37 GMT+02:00 John D. Gwinner <john@gwinner.org>:

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