W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Canvas resetClip() API

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 21 Jan 2014 22:17:04 +0000 (UTC)
To: Simon Fraser <smfr@me.com>
Message-ID: <alpine.DEB.2.00.1401212213390.26647@ps20323.dreamhostps.com>
Cc: "whatwg@lists.whatwg.org Group" <whatwg@lists.whatwg.org>, Rashmi Shyamasundar <rashmi.shyam@gmail.com>
On Tue, 8 Oct 2013, Simon Fraser wrote:
> 
> I donít like the resetClip() API, and donít think it should be added to 
> canvas.
> 
> The reason resetClip() is a bad API is that it breaks the ability to 
> robustly modularize drawing code. For example, say that you have the 
> following code:
> 
> context.save();
> // Ö set up a path to clip to
> context.clip();
> someJSLibrary.drawSomething();
> context.restore();
> 
> In the absence of resetClip(), you are guaranteed that 
> someJSLibrary.drawSomething() canít draw outside of the clip you 
> specified. With resetClip(), that JS library can draw wherever the heck 
> it wants, which may totally break your canvas drawing.

That's true anyway; for example, the JS library could call 
context.restore() to escape your clip(), or could call save() more times 
than it calls restore(). At the end of the day, you have to have a 
contract with your library, and in that there might be "you obey my clip" 
or "you obey my transforms" or "you obey my transforms but it's ok if you 
unclip" or whatever.


> If you really need resetClip() in your own drawing code, youíre probably 
> doing it wrong.

Why is it more wrong to need resetClip() than to need resetTransform()?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 21 January 2014 22:17:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC