On Mon, Jul 6, 2015 at 2:38 PM, Ashley Gullen ash...@scirra.com wrote:
I thought it would be more confusing to have separate competing proposals in
one document? They are more like three revisions of the same document
anyway, the latest one including all feedback and rationale so far:
I'm new to writing specs and when I first looked ReSpec had templates and a
guide - is there something similar for the HTML standard style spec?
I changed toBlob to use a dictionary (still at
https://www.scirra.com/labs/specs/imagedata-conversion-extensions.html).
Ashley
On 7 July 2015 at
On Tue, Jul 7, 2015 at 12:24 PM, Ashley Gullen ash...@scirra.com wrote:
I'm new to writing specs and when I first looked ReSpec had templates and a
guide - is there something similar for the HTML standard style spec?
I think you can tweak ReSpec to do the right thing, though most new
I thought it would be more confusing to have separate competing proposals
in one document? They are more like three revisions of the same document
anyway, the latest one including all feedback and rationale so far:
https://www.scirra.com/labs/specs/imagedata-conversion-extensions.html
On 3 July
On 2 July 2015 at 21:36, Jeff Muizelaar jmuizel...@mozilla.com wrote:
The important ones of these are:
Blob - ImageData
HTMLImageElement - ImageData
ImageData - Blob
These conversions are covered by what I proposed in my previous email, so I
drafted another spec with them:
On Fri, Jul 3, 2015 at 1:51 PM, Ashley Gullen ash...@scirra.com wrote:
These conversions are covered by what I proposed in my previous email, so I
drafted another spec with them:
https://www.scirra.com/labs/specs/imagedata-conversion-extensions.html
Could you please put them all in a single
I'm not sure having a hub is worth the implementation pain.
It looks like there are three pretty different things here:
ImageBitmap - Immutable images for drawing on canvas. Typically
premultiplied data located on the GPU
ImageData - Mutable script accessible array of data. Unpremultiplied
data
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
If it's difficult to make ImageBitmap both an efficient drawing source and
a conversion intermediary, then we could add conversion functions to each
object that can be converted, e.g.:
HTMLImageElement.toBlob()
HTMLImageElement.toImageData()
Blob.toImageData()
ImageData.toBlob()
This seems
On 6/26/15 4:07 AM, Ashley Gullen wrote:
I don't think we should extend HTMLImageElement because it is not
available in workers. Adding the conversion methods to ImageBitmap
allows workers to perform conversions using Blob (compressed image data)
in the place of HTMLImageElement.
Maybe I
Gosh, I keep putting the wrong terms in and it really confuses things. I
need to get better at writing clearly! I mentioned transferToImageBitmap
when I meant transferToImageData. The parargraph from my second-last
email should read:
I like the suggestion that ImageBitmap be the hub of image
I'm also wondering that if we have ImageBitmap.transferToImageData(),
should we not also have ImageData.transferToImageBitmap()? Currently
createImageBitmap(imageData) appears to require making a copy.
On 26 June 2015 at 12:07, Ashley Gullen ash...@scirra.com wrote:
I've updated the draft with
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
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
ImageData without redundantly copying the pixel data.
I don't think we should extend
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
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()
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
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 close
the ImageBitmap you transferred to an ImageData.
Transfer:
On 6/24/15 1:28 PM, Ashley Gullen wrote:
I'm new to specs and WebIDL, my intent was to say those are new methods
on ImageBitmap. Is partial interface ImageBitmap the correct way to
say that?
Yes, it is.
The wording of undue latency in the ImageBitmap spec does not appear
to rule out
On Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The drawback of adding toBlob/toImageData to the various things ImageData
can be constructed from is that it's a bit more spec complexity, but I don't
see that as a showstopper, necessarily.
We should probably stick to the
Good point - it makes sense to have ImageBitmap as the hub of all
conversion.
I've drafted a new spec which instead proposes ImageBitmap.toBlob() and
ImageBitmap.toImageData():
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
This should cover all conversion cases
Sorry for the confusion. Yes, the latest URL is:
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
I'm new to specs and WebIDL, my intent was to say those are new methods on
ImageBitmap. Is partial interface ImageBitmap the correct way to say
that? (I updated the URL to say
On Wed, Jun 24, 2015 at 1:28 PM, Ashley Gullen ash...@scirra.com wrote:
Sorry for the confusion. Yes, the latest URL is:
https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html
I'm new to specs and WebIDL, my intent was to say those are new methods on
ImageBitmap. Is partial
On 6/19/15 5:43 AM, Ashley Gullen wrote:
I've not done this before, so I've no idea if this is the right/useful
approach, but I drafted a spec for it here:
https://www.scirra.com/labs/specs/imagedata-blob-extensions.html
Let me know if you have any feedback on this.
Ashley,
I assume the
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.
.
*From:* a...@scirra.com [mailto:a...@scirra.com] *On Behalf Of *Ashley
Gullen
*Sent:* Wednesday, June 17, 2015 2:06 PM
*To:* Travis Leithead
*Cc:* public-webapps@w3.org
*Subject:* Re: Async Image - ImageData conversion
That seems like a good start. I suppose there should
[mailto:a...@scirra.com] *On Behalf Of *Ashley
Gullen
*Sent:* Wednesday, June 17, 2015 2:06 PM
*To:* Travis Leithead
*Cc:* public-webapps@w3.org
*Subject:* Re: Async Image - ImageData conversion
That seems like a good start. I suppose there should be a
putImageDataAsync counterpart too
...@scirra.com] On Behalf Of Ashley Gullen
Sent: Wednesday, June 17, 2015 2:06 PM
To: Travis Leithead
Cc: public-webapps@w3.org
Subject: Re: Async Image - ImageData conversion
That seems like a good start. I suppose there should be a putImageDataAsync
counterpart too? Then we can do:
Blob - Image via: load
I think solving at least the first-order problem of extracting data from the
Canvas async is do-able.
Something like:
PromiseImageData getImageDataAsync(x,y,w,h);
seems sensible to add ☺
From: a...@scirra.com [mailto:a...@scirra.com] On Behalf Of Ashley Gullen
Sent: Wednesday, June 17, 2015
That seems like a good start. I suppose there should be a putImageDataAsync
counterpart too? Then we can do:
Blob - Image via: load blob URL
Blob - ImageData via: load blob URL - Canvas drawImage
- getImageDataAsync
Image - Blob via: Canvas drawImage - Canvas toBlob
Image - ImageData via: Canvas
30 matches
Mail list logo
