WICG / priority-hints

A browser API to enable developers signal the priorities of the resources they need to download.
https://wicg.github.io/priority-hints/
Other
271 stars 26 forks source link

Integer values for importance attribute #44

Closed canadaduane closed 2 years ago

canadaduane commented 4 years ago

Would it be possible to use integer values instead of "low" and "high" importance? My use case is as follows:

We are building an OpenGL game world in which it's possible to calculate distance from the player to various resources in the game world. We would like to queue those resources (texture files, mesh files, etc.) to be loaded such that the nearest resources are loaded first, then a little farther out, and a little farther out, and so on.

We use THREE.js, and its underlying image texture loading is done by creating an "img" tag, then setting the "src" attribute to a URL.

Something like this would be perfect in our situation (programmatically added, of course):

<img src="/assets/nearest.png" importance="99">
<img src="/assets/near.png" importance="252">
<img src="/assets/farther.png" importance="305">
<img src="/assets/wayoutthere.png" importance="1090">

These integer values, in combination with Priority Hints, would allow us to help the our game queue up images to load in order of proximity (i.e. Math.sqrt(x^2 * y^2)) without loss of significant information to the browser.

canadaduane commented 4 years ago

BTW I have an open pull request on Three.js here that allows for the importance to be set on img tags used by Three.js for textures: https://github.com/mrdoob/three.js/pull/19458

addyosmani commented 4 years ago

Thanks for raising this issue, @canadaduane. When we originally discussed introducing integer values for Priority Hints, some of the pushback I recall was...

Of these reasons, I think the lack of consistency in how browsers approach "priority" is the big one for me. It's more manageable to map high level values than more explicit ones.

canadaduane commented 4 years ago

Two thoughts:

  1. Could we future-proof the spec, and explicitly call out "low" as mapping to value "0" and "high" as mapping to value "1"? This could allow a path forward such that low/high is implemented now, and integer values are implemented at a later date.

  2. I'm not in the thick of things as you are, but it seems like the value of priority hints is only in ambiguous priority queues where several resources are "tied" and we would prefer to have sensible tie-breaking behavior. Since these importance values are merely hints, it seems useful to provide as much information as possible. This would allow browsers to use as much or as little as seems appropriate for the nuances of their implementations.

I guess I have one last thought: as a writer of HTML (and not transport-layer protocols) I have very little awareness of QUIC/H2 and would not find that confusing at all (ignorance is bliss?)

pmeenan commented 3 years ago

I'd be concerned that assigning a specific value to the hint would imply more control than the hint actually carries and low/auto/high coveys the general "nudge" nature of what hints would actually impart.

Generally, given all else being equal, within the same priority the requests will go out in the order they are discovered so finer-grained control might come from sequencing the texture requests in the order you'd prefer to get them. That said, there's also still no guarantee that you'll get the responses back in the same order. A lot of HTTP/2 origins will just return them in a random order depending on what comes out of cache first.

Real fine-grained control likely requires web transport or a cooperating origin with known behavior.