- From: Oliver Hunt <oliver@apple.com>
- Date: Mon, 30 Jun 2008 17:18:29 -0700
> > > So now we need to define levels of graphic burden? and at what level > of burden does the quality suffer? Seems just as hard to define. > Having the author explicit say "this has to be as high quality as > possible" or "less can be low quality" seems better and we have > examples of other specs offering the same kind of control. > No. The whole point is that the UA is in the best position to identify what the tradeoffs are, not the author -- if you want a flag to specify the quality to be used then that would require you to determine what the tradeoffs were yourself, with no substantial knowledge of what combination any given user was actually using. You need to realise that different UAs and different platforms have substantially different performance characteristics. And that said how would you make the decision yourself anyway? Your decision will almost always hurt *some* portion of your userbase, either through lower quality than would otherwise be possible, or by making a page that is unusable for someone with a lower powered device. And then, after you've made that decision you will start getting some people saying UA1 looks better than UA2 because you underestimated performance of the UAs, and UA1 ignores the flag. Or you'll get people saying UA1 is unusable because you found it was slow in UA2, so you dropped the quality setting -- which UA1 ignores, but then a year later you get people saying UA1 looks better again because hardware is faster so it now do its higher quality rendering without any problem -- but UA2 is still using the low quality path. Finally you test on UA1 and UA2, and find your site looks good in one, but is too slow in the other, do you now lower the quality in both so that your site is usable in both, or do you try and make the decision in JS at runtime? If the latter you now have quite a bit more work to do. How do you determine the performance of a particular UA/platform combination? JS performance is not the same as canvas, so you have to manually test canvas performance, so you are now trying to hand code what could already be built into the UA. Alternatively you could just try to take the lazy path and do a UA check, and try to determine the performance based on UA but now you have *all* of the standard UA check problems, and you still can't test the real performance because you don't know what hardware you're on. If the UA makes its own decisions about performance, it can make a decision based on a wide range of information that you do not have any access to, in addition to being aware of the specific costs of certain operations (eg. a UA could choose to lower the quality of only a single operation, like image scaling, but leave other operations at their standard fidelity -- trying to do this in a flag would be both horrifically complicated for authors *and* would represent tremendous over specification by the standard) --Oliver
Received on Monday, 30 June 2008 17:18:29 UTC