- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 05 Jun 2007 10:37:08 -0500
- To: Laurens Holst <lholst@students.cs.uu.nl>
- CC: "public-html@w3.org" <public-html@w3.org>
Laurens Holst wrote: > Of course an O(log n) operation is going to be slower than an O(1) > operation. However, is the impact significant enough to ever be noticed > by the user? I mean, in what scenarios do images swap? The one _I_ run into it the most it is browser benchmarks which are then widely published as "speed comparisons". The second-most common (trailing very little) is DHTML-based games where images swap on every time-step depending on what else is going on in the game. So every 10ms, ideally. Often for thousands of images (every single sprite, etc). > They swap when the user clicks a button in a picture viewer, or when the user hovers > over something. That also happens, but clearly the performance is less of an issue here. > By the way, blitting a bitmap still seems a much slower operation than > calling a function recursively a dozen or so times. Not necessarily: blitting a bitmap can be much better optimized to only happen as often as needed for smooth operation from the POV of the user (e.g. put the paint off on an event), while the base URI stuff has to happen as often as the script asks for it. In practice, UAs "drop frames" in a lot of existing DHTML animations... > In fact, contrary to what I thought earlier, this already seems to be > implemented in Firefox. Not for HTML. We implement all sorts of slow things for content that's not really used. Optimizing it is just much lower priority, and in practice people don't push its boundaries as much. > Well, if you think it’s acceptable for html:base :). It’s a pragmatic > solution, I admit, but if that’s the only thing that works for browser > vendors then it’s better than no solution I'm not convinced that's true. I wouldn't say that html:base _works_ for browser vendors. More that they suffer it because they need to for compat with existing content... Implementing it compatibly is really quite a bit of a pain. > By the way, are there really any sites that depend on the current > behaviour that when <base>’s href attribute is changed, the images don’t > change? No idea. ;) >> It doesn't, since the base URI is stored on the document. > > No, this is also true when xml:base is used. So it can’t be that it’s > stored on the document. It's looked up recursively for non-HTML, just grabbed off the document for HTML. > Well, that is assuming that you let the images re-evaluate. No. As I said earlier, xml:base also slows down any DOM mutations involving images (moving them in the DOM). > Unless you have a proposal for how to implement xml:base-like > functionality without any performance impact? I don't, yet. I admit that it's very tempting functionality, but the xml:base setup is a _huge_ pain currently. We need to think of something better. > However, re-setting an image’s URL does not result in the > new baseURI being used Huh? Testcase? -Boris
Received on Tuesday, 5 June 2007 15:37:20 UTC