On Tue, Jul 7, 2015 at 12:24 PM, Ashley Gullen 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
specifications are written
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 10:48
On Mon, Jul 6, 2015 at 2:38 PM, Ashley Gullen 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:
> https://www.scirra.com
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 Fri, Jul 3, 2015 at 1:51 PM, Ashley Gullen 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 document? That wo
On 2 July 2015 at 21:36, Jeff Muizelaar 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:
https://www.scirra.com/labs/spe
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 l
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 incons
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 wasn't
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 i
On Fri, Jun 26, 2015 at 7:07 AM, Ashley Gullen 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
> ImageData without redu
On Thu, Jun 25, 2015 at 4:57 PM, Boris Zbarsky 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 anoth
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 wrote:
> I've updated the draft with an ImageBitmap.t
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 Thu, Jun 25, 2015 at 1:57 PM, Boris Zbarsky 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 pattern of eit
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 Image
On Thu, Jun 25, 2015 at 9:40 AM, Justin Novosad wrote:
>
>
> On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen 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 efficient
On Thu, Jun 25, 2015 at 5:56 AM, Ashley Gullen 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 close the ImageBit
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:
createImageBitma
On Wed, Jun 24, 2015 at 1:28 PM, Ashley Gullen 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 interface Imag
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 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
Ashley,
We at Mozilla were just discussing this proposal, and we have a
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 rele
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 asynch
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.
ent with it and get
>> broader community feedback on the idea.
>>
>>
>>
>> *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-
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
...@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
>
>
> seems sensible to add J
>
>
>
> *From:* a...@scirra.com [mailto:a...@scirra.com] *On Behalf Of *Ashley
> Gullen
> *Sent:* Wednesday, June 17, 2015 10:00 AM
> *To:* public-webapps@w3.org
> *Subject:* Async Image -> ImageData conversion
>
>
>
> I wa
To: public-webapps@w3.org
Subject: Async Image -> ImageData conversion
I was wondering if there is anything on the standards track to asynchronously
get an ImageData object from an Image?
We have a web app dealing with large sprite sheets (up to 2048x2048), and at
some point we need to get
I was wondering if there is anything on the standards track to
asynchronously get an ImageData object from an Image?
We have a web app dealing with large sprite sheets (up to 2048x2048), and
at some point we need to get an ImageData for this. Currently the only way
I know of doing this is via a ca
32 matches
Mail list logo
