[whatwg] Proposal: Add CanvasRenderingContext2D.currentTransform for reading and writing the current transform matrix

An important canvas use case that arose during the development of pdf.js[1] is implementing a "fill-to-current-clip" operation. In PDF, the shading fill operator, "sh", requires this. In the cairo library, cairo_paint() is this operation. The operation can be implemented by tracking the curre

[whatwg] Proposal: Add CanvasRenderingContext2D.setDash()/.getDash()/.dashOffset for dashed stroking

Most 2d graphics libraries support stroking paths with a "dash pattern" of on/off strokes. Canvas should have it for completeness. Because SVG already offers a facility for dashed stroking, adding it to canvas is not expected to be a big burden on implementors who have also implemented SVG. I

[whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with "nonzero" (default) and "evenodd" options

In 2D canvas, determining whether a point is "inside" a path is currently always done using the non-zero winding rule. I propose extending 2D canvas to allow determining inside-ness using the even-odd rule. The motivation is (1) Many/most 2D graphics libraries have this feature; canvas should

Re: [whatwg] [WebWorkers] About the delegation example

Chris Jones wrote: If I were writing a computationally-bound webapp, I would want an interface like [main thread] SharedWorker.parallelMap(workerfn [, ...]]) [worker thread] function workerfn(myThreadIndex, numberOfworkerfns [, ...]) { // partition problem dataset [...] based on

Re: [whatwg] localStorage mutex - a solution?

Rob Ennals wrote: Missed out the important final qualifier. Here's take 3: "the user agent MUST NOT release the storage mutex between calls to local storage, except that the user agent MAY release the storage mutex on any API operation /other that a local storage oeration/" IMHO, this is a

Re: [whatwg] [WebWorkers] About the delegation example

David Bruant wrote: > On the other hand, on a 16-core processor (which doesn't exist yet, but > is a realistic idea for the next couple of decades), the task could be > executed faster with 16 workers. > Maybe you mean "hardware thread" instead of "core"? If so, the machine I'm writing this mes

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Jeremy Orlow wrote: Those who want a queue. I.e. those who want an asynchronous callback based interface and the UA will only call one callback at a time. Perhaps on a per-origin basis. Note that this can never "fail", need to be rolled back, etc. This sou

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Jeremy Orlow wrote: On Wed, Sep 9, 2009 at 4:39 AM, Chris Jones <mailto:cjo...@mozilla.com>> wrote: Aaron Boodman wrote: On Tue, Sep 8, 2009 at 11:23 AM, Chris Jonesmailto:cjo...@mozilla.com>> wrote: In general, I agree with Rob about this

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Chris Jones wrote: Jonas Sicking wrote: On Tue, Sep 8, 2009 at 1:38 PM, Chris Jones wrote: Type (c) web apps would need to use the check |window.transaction === undefined| to determine whether *transactional* localStorage was supported, and thus aren't affected by either proposal.

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Jonas Sicking wrote: On Tue, Sep 8, 2009 at 1:38 PM, Chris Jones wrote: No one has responded directly to my original proposal of making |window.localStorage === undefined| until |window.transaction| or whatever has been accessed. Unlike your proposal and a similar one from Jeremy, mine is a

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Benjamin Smedberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/8/09 3:00 AM, Aaron Boodman wrote: On Fri, Sep 4, 2009 at 12:02 AM, Chris Jones wrote: I propose adding the functions window.localStorage.beginTransaction() window.localStorage.commitTransaction() or

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Aaron Boodman wrote: On Tue, Sep 8, 2009 at 11:23 AM, Chris Jones wrote: In general, I agree with Rob about this proposal. What problem with storage mutex as spec'd today does your proposal solve? The spec requires a single storage mutex for the entire UA. Therefore in a MELUA a web pag

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

In general, I agree with Rob about this proposal. What problem with storage mutex as spec'd today does your proposal solve? I'm eagerly willing to concede explicit beginTransaction()/commitTransaction() for a window.transaction() wrapper that implicitly does those. Aaron Boodman wrote: On

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Robert O'Callahan wrote: On Sun, Sep 6, 2009 at 4:55 AM, Chris Jones <mailto:cjo...@mozilla.com>> wrote: I mean prevent the UA from affecting a script's execution. The cases I've thought of so far where we will probably have to break storage-mutex sem

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Robert O'Callahan wrote: On Sat, Sep 5, 2009 at 10:22 AM, Chris Jones <mailto:cjo...@mozilla.com>> wrote: And if the intention is to make scripts appear to run atomically, then I think there are better ways to specify that than storage mutex. That sounds good, how? My

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Robert O'Callahan wrote: On Fri, Sep 4, 2009 at 9:44 PM, Jeremy Orlow > wrote: I think it's pretty clear that the spec, as is, is not possible to implement without making it trivial for a single website to lock up all of your event loops I don't thin

Re: [whatwg] RFC: Alternatives to storage mutex for cookies andlocalStorage

is way. It seems confusing to have cookies be "sometimes transactional, sometimes not," although your proposal is certainly feasible. The side-effect ("stomp") notification for cookies seems like a separate, and good, idea, irrespective of localStorage. Cheers, Chris Best r

Re: [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

Jeremy Orlow wrote: I mostly agree with your assertions about the type of developer who's using localStorage. It sure would be nice if we could give developers powerful APIs and keep them simple and make it possible to implement them in a performant manner. Unfortunately, I think the current

[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

I'd like to propose that HTML5 specify different schemes than a conceptual global storage mutex to provide consistency guarantees for localStorage and cookies. Cookies would be protected according to Benjamin Smedberg's post in the "[whatwg] Storage mutex and cookies can lead to browser deadlo