- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 08 Aug 2014 21:57:26 -0400
- To: Justin Novosad <junov@google.com>
- Cc: whatwg <whatwg@lists.whatwg.org>
On 8/8/14, 9:46 PM, Justin Novosad wrote: > The way you measured the JS crossing time does not include parameter > validations if I am not mistaken. It includes the validation Web IDL does (e.g. "this is an HTMLImageElement") but not the specific validation this method does, correct. > If you have 1000 sprite draws that > draw from the same sprite sheet, that is 1000 times you are verifying > the same image parameter (verifying that the image is complete, that its > security origin does not taint the canvas, fetch the decoded image data, > etc.), even tough most of this stuff is cached, it is being looked up N > times instead of just once. True. I just tested this in a Firefox nightly: I put the early return after we have looked up the decoded image data in our internal cache, or gotten it from the image if not cached, but before we've started doing anything with the position passed to drawImage. The internal cache lookup already includes checks for things like tainting, completeness verification, etc, since there is nothing in the cache if the image is not complete and the canvas is already tainted as needed if we have cached decoded data for this (image,canvas) pair. This version of drawImage takes about 47ns per call when averaged over 1e5 calls (of which, recall, 17ns is the JS call overhead; the other 30ns is the cache lookup, which hits). That's starting to creep up into the 1.5% range of the time I see drawImage taking in the fastest drawImage implementation I have on hand. > I will prototype this and come back with some hard data. That would be awesome! -Boris
Received on Saturday, 9 August 2014 01:57:52 UTC