Based on feedback received from web developers, new APIs that move image
data around should also strive to eliminate intermediate copies of the
image data to avoid memory bloat. I think your proposal achieves that, but
I think memory footprint reduction could be a stated objective of the
proposal.
On Thu, Jun 25, 2015 at 9:40 AM, Justin Novosad ju...@google.com wrote:
On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen ash...@scirra.com wrote:
I see that OffscreenCanvas also specifies a close() method for
ImageBitmap. Perhaps browsers could use copy-on-write with the
toImageData() method
On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen ash...@scirra.com wrote:
I see that OffscreenCanvas also specifies a close() method for
ImageBitmap. Perhaps browsers could use copy-on-write with the
toImageData() method? Then you can efficiently either transfer or copy
depending on if you
Making ImageData the hub would imply more copies in memory in many cases.
Because ImageData is mutable (not to mention the alpha multiplication
issues which are also a factor), it cannot share its image buffer with the
source it was created from, unlike ImageBitmap. Immutability is a
significant
On Thu, Jun 25, 2015 at 4:57 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/24/15 1:28 PM, Ashley Gullen wrote:
Note for devices with discrete GPUs, it's possible that ImageBitmap
stores the decompressed image data in a GPU texture but does not have it
in system RAM.
Indeed. This is
On Fri, Jun 26, 2015 at 7:07 AM, Ashley Gullen ash...@scirra.com wrote:
I've updated the draft with an ImageBitmap.transferToImageData() method:
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
It's also used in Example 2 to demonstrate converting a Blob to an
