Bug 71270 - [chromium] Experiment in <canvas>.toBlob
Summary: [chromium] Experiment in <canvas>.toBlob
Status: RESOLVED DUPLICATE of bug 148878
Alias: None
Product: WebKit
Classification: Unclassified
Component: Canvas (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: noel gordon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-01 00:39 PDT by noel gordon
Modified: 2017-03-08 17:56 PST (History)
9 users (show)

See Also:

Attachments
Experiment uno: multiple threads. (26.03 KB, patch)
2011-11-01 00:42 PDT, noel gordon 		no flags Details | Formatted Diff | Diff
Experiment due: sequential workqueue. (27.27 KB, patch)
2011-11-01 01:20 PDT, noel gordon 		no flags Details | Formatted Diff | Diff
Patch: sequential workqueue. (22.61 KB, patch)
2011-12-19 06:02 PST, noel gordon 		no flags Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description noel gordon 2011-11-01 00:39:46 PDT 
Experiments with <canvas>.toBlob
Comment 1 noel gordon 2011-11-01 00:42:51 PDT 
Created attachment 113139 [details]
Experiment uno: multiple threads.
Comment 2 noel gordon 2011-11-01 01:20:50 PDT 
Created attachment 113142 [details]
Experiment due: sequential workqueue.
Comment 3 noel gordon 2011-12-19 05:56:45 PST 
I prefer the sequential workqueue approach, it simpler to reason about and provides good sequential performance with no thread contention unlike the "experiment uno".

Parts of "experiment due" dealt with the mimeType detection changes in HTMLCanvasElement.cpp and changes to the toDataURL() area of ImageBufferSkia.cpp.  These made the patch harder to read.  I cut them out and submitted them separately to focus the patch on the toBlob() idea.  FIXME notes suggest the changes needed to the toBlob() spec prose.
Comment 4 noel gordon 2011-12-19 06:02:53 PST 
Created attachment 119856 [details]
Patch: sequential workqueue.
Comment 5 Alexey Proskuryakov 2012-02-22 17:33:23 PST 
How is this related to bug 51652?
Comment 6 Yong Li 2012-07-30 10:40:41 PDT 
(In reply to comment #4)
> Created an attachment (id=119856) [details]
> Patch: sequential workqueue.

Is this patch for review? Are you still working on this bug? Thanks.
Comment 7 Chris Cinelli 2014-10-25 12:29:20 PDT 
This is still open from 2011! 
Are the people assigned to this ticket still the right ones to implement it or maybe it need to be reassigned?

When I try to save 41Mpixel images, Chrome crashes. Currently we have to allocate more memory to run through the intermediate ASCII buffer returned by toDataURL and use the Uint8Array to convert in binary.

This is the only thing that prevent us to make our WebGL picture editor works with images bigger than 20Mpixels. Regarding the rest, it is actually better and faster  than Lightroom.
Comment 8 David Kilzer (:ddkilzer) 2016-01-25 11:37:24 PST 
Chrome has implemented this:
<https://twitter.com/chromiumdev/status/691687552000995328>

I'm not sure if there is standards support yet.
Comment 9 David Kilzer (:ddkilzer) 2016-01-25 11:38:56 PST 

*** This bug has been marked as a duplicate of bug 148878 ***
Comment 10 noel gordon 2017-03-08 17:56:35 PST 
(In reply to comment #8)
> Chrome has implemented this:
> <https://twitter.com/chromiumdev/status/691687552000995328>
> 
> I'm not sure if there is standards support yet.

Mentioned on the duped-to bug, standards prose is there.  I used the patch on this bug to inform and help write the spec prose (with Ian Hickson).