Integer values for importance attribute
canadaduane opened this issue · 4 comments
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.
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: mrdoob/three.js#19458
Thanks for raising this issue, @canadaduane. When we originally discussed introducing integer values for Priority Hints, some of the pushback I recall was...
- Resource priorities are unspecified and we felt there would be an uphill battle to define these in a way that factored in the different nuances for how each browser approaches prioritization. This was one reason we opted for a higher-level label (low/high) rather than absolute values.
- The definition of a dependency tree of importance values (effectively) in markup can be complex (you could imagine us ending up in a scenario where, similar to z-index, teams complete for their priority to be a specific value that tops the others).
- There isn't a direct mapping between browser priorities and QUIC/H2 prios. There was a little concern that specific values may give folks the impression there was a tighter relationship between them than there is.
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.
Two thoughts:
-
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.
-
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?)
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.