Re: Hello & a proposal

On Thu, Jul 23, 2015 at 1:13 PM, Ashley Gullen <ashley@scirra.com> wrote:

> I arrived at this group from https://www.w3.org/community/wicg/ where
> there is no mention of discourse! It looks more active than this mailing
> list so I guess I'll make another post about this there.
>
> Previous discussion on public-webapps starts here:
> https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0908.html
>
> My key takeaways from the feedback were:
> - the API should be designed to avoid intermediate copies of the data,
> which increase the memory overhead (this sounds like it rules out using a
> worker)
> - ImageBitmap is probably not a good conversion source, since it may be a
> premultiplied resource on the GPU
> I incorporated this feedback to the latest draft.
>
> As a web developer working on my own projects, I don't really feel like
> I'm in a position to speak for the projects of other web developers. I
> guess I read similar blogs and the odd Hacker News post, but I don't feel
> like I have an answer to "why do other sites need this?" - am I supposed to
> be a spokesperson for all developers?
>

Not really. If you're not aware of other developers/sites that have ran
into the same problem, that's quite alright. The post on discourse is
exactly the right tool in order to find them :)


> I think this feature is useful in a general-purpose way to any web app
> that does any kind of image processing, but I'm speculating.
>

FWIW, I tend to agree with your speculation.


>
> Here's a realistic example of our own use case: the user drag and drops a
> zip file in to the page. The zip contains 1000 PNGs (this is a realistic
> workload in our case, not a number I have just fabricated). I want to
> process these images based on their ImageData. To get the ImageDatas,
> currently the only solution is loading the blobs by some means, then
> synchronous use of drawing then getImageData on a canvas. If you have 1000
> images, doing it all synchronously will take so long that either the
> browser or OS will assume the page has frozen. It can be sliced up over
> separate frames with timers so the browser keeps responding, but you are
> still limited by the speed of a single core when the problem is perfectly
> parallelisable, and the deliberate idle time to let the browser respond
> slows down the overall processing speed. So overall you get to work at
> about 75% of the speed of one core, when you could be using all cores. The
> async methods I proposed allow the browser to schedule this over all cores,
> significantly increasing performance, and saves me having to worry about
> how to schedule a long queue of synchronous calls while still allowing the
> browser to respond. (requestIdleCallback may help solve this, but still
> will use less than one full core.)
>
> All I need for this use case is an async ImageData.create function, but I
> expanded the spec to cover more general purpose use cases to do with image
> processing. Many of the use cases for getImageData/putImageData can
> probably use these methods instead, and avoid synchronous jank. I guess I
> should cover this in the spec draft?
>

Yeah, that'd be great!