W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] WebWorkers and images

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 13 Jan 2011 21:35:38 -0500
Message-ID: <4D2FB67A.6080304@mit.edu>
On 1/13/11 6:38 PM, Glenn Maynard wrote:
> It might be possible to optimize the allocation further, but even
> 2.5ms is worth optimizing out.  If you're trying to maintain 60 FPS
> (16.6ms per frame), that's 15% of your total available time (ignoring
> concurrency).

Indeed.  One more note.  My 2.5ms for 9.2MB number means that I can copy 
about 3.7GB per second.  This has to be read from RAM and then written 
back to RAM, since it doesn't fit in the cache, for a total of 7.4GB 
moving on the memory bus.  My memory bus has a peak transfer rate of 
about 17GB/s, if I read the documentation right (2133 MT/s, and 64-bit 
transfers).  So the best I could possibly expect with that hardware, if 
there were no other memory traffic and the prefetcher were perfect (so 
there is never any latency) is to cut that time by a factor of 2 or so.

In other words, this isn't something that can be sped up significantly 
by clever coding in browsers or libraries or compilers or whatnot.  If 
we have to copy that much data, it will just take several milliseconds 
given current hardware.  The only way to do it faster is to not copy the 
data.

-Boris

P.S.  There's one more thing here, though.  In my case, the imagedata is 
9.2MB, but for your typical 1440x900 15" laptop it's closer to 5.2MB. 
Which helps somewhat.  Of course for your typical high-res 30" desktop 
monitor running at 2560x1600 we're talking 16.4MB.  All of which is to 
say that this idea of making fullscreen canvas fast really depends on 
the screen involved if we have to move the data around.
Received on Thursday, 13 January 2011 18:35:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC