Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions

[Dean Jackson]

On 07/07/2012, at 10:11 AM, Charles Pritchard  wrote:

>> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor  wrote:
>>> As things currently stand in the spec, implementations basically need to
>>> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
>>> doubt any implementors would be enthusiastic to implement hit regions
>>> like this. From a WebKit perspective, we'd much prefer keeping a Path
>>> for each hit region, and then simply using isPointInPath for hit
>>> testing. This also implies that the current piggybacking of "Clear
>>> regions that cover the pixels" in clearRect() could go away. Yay! :)
>> 
>> Bog-standard hit-testing algorithms apply.  Keep a single extra canvas
>> around, draw each region into it with a different color.  When you're
>> hit-testing, just see what color that pixel is, and look up which
>> region is associated with it.  This is extremely fast and simple to
>> implement, and has all the right properties - the "topmost" region for
>> a given pixel is the one returned.

We're aware of this technique, but it has a couple of obvious issues:

1. It requires us to create a duplicate canvas, possibly using many MB of RAM. 
It's generally going to be less memory to keep a list of geometric regions. And 
performance won't be terrible if you implement some spatial hashing, etc.

2. It doesn't allow for sub pixel testing. In your algorithm above, only one 
region can be at a pixel (which also means it isn't our standard drawing code 
with anti-aliasing). Consider a zoomed canvas, where we might want more 
accurate hit testing.

Dean

[whatwg] [canvas] Proposal for supportsContext

[Dean Jackson]

I sent this to the public-h...@w3.org list:

http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3058d24...@apple.com

Copied below.

[[[

I propose adding a new method to HTMLCanvasElement:

interface HTMLCanvasElement : HTMLElement {
  boolean supportsContext(DOMString contextId, any... arguments);
};

supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.

The justification for this method is that it is sometimes expensive to create a
context. Many authors test for a canvas feature by trying to create a context,
examining the return value, and doing something different if the context was
null. This is ok in most cases, but there are some instances where we don't
want to create a context unless the page is really going to make use of it.

To give a real world example, the popular tool Modernizr tests for the
availability of WebGL by attempting to create a WebGL context. This can happen
even on pages that have no intention of using WebGL - an author has just
inserted Modernizr into their page and is using it to test for another feature.
As I said, creating a context is not a free operation. In fact, on shipping
Safari (Mountain Lion) this causes us to switch to a more powerful GPU
on systems that have two graphics processors.

An alternative (for the WebGL case) would be to have the author test for the
presence of window.WebGLRenderingContext. However, this is not reliable. We may
ship a browser that supports WebGL, but not on the particular hardware
configuration that the user is running. Or it could be a momentary
unavailability. There are a number of visible top-level WebGL apis, and we
don't want to have to hide/show them all based on availability.

]]]

Dean

Re: [whatwg] [canvas] Proposal for supportsContext

[Dean Jackson]

On Sep 10, 2012, at 12:28 PM, Tobie Langel  wrote:

> On Sep 10, 2012, at 8:14 PM, Dean Jackson  wrote:
> 
>> I propose adding a new method to HTMLCanvasElement:
>> 
>> interface HTMLCanvasElement : HTMLElement {
>> boolean supportsContext(DOMString contextId, any... arguments);
>> };
>> 
>> supportsContext takes the same parameters as getContext, and simply returns
>> true if the corresponding call to getContext would have returned a valid
>> context, false otherwise.
> 
> What about enabling feature detection by providing a method per context?
> 
> interface HTMLCanvasElement : HTMLElement {
>  object get2DContext();
>  object getWebGLContext(any... args);
> };
> 
> That way, developers can use idiomatic JS for feature testing like
> pretty much everywhere else on the Web platform:
> 
> if (canvas.get2DContext) {
>  // do stuff with 2D canvas
> }

This doesn't address the problem we are hitting, which is that
it is expensive to create a context. It's also a big change to
an existing operational API.

I'm looking for some way an implementation can suggest that
it supports a particular context without the user having to
create one. As James Robinson pointed out in the WebKit IRC
channel, even the implementation might not know for sure it can
create the context, but I think that's ok. The important
thing is that returning false from supportsContext means that
a corresponding call to getContext would fail.

Dean

Re: [whatwg] [canvas] Proposal for supportsContext

[Dean Jackson]

On Sep 10, 2012, at 12:35 PM, Ashley Gullen  wrote:

> Can't Modernizr just lazy load the WebGL context?  (i.e. only try to create a 
> context if the web page actually asks if WebGL is supported)

Yes, it could. But we don't control Modernizr or any other scripts people might 
use. I'd rather provide something at the browser-level to protect from bad 
practice than expect every page to behave nicely.

> On the other hand I would love to see a supportsContext function which can 
> tell if WebGL is software rendered (i.e. Swiftshader in Chrome).  There's 
> been a lot of discussion about that and how to define it, but in our 
> experience 2D games rendered with Swiftshader are far slower than rendered 
> with a software-rendered 2D canvas.  We have production code in the wild 
> which detects Swiftshader by its supported WebGL extensions.  I'd love to 
> replace this even with something vendor specific, like:
> 
> canvas.supportsContext("webgl", { "-webkit-allowswiftshader": false })

Yes, that was another part of the eventual plan, although I didn't want to 
define that yet.

Dean

> 
> Despite the hardness to define it, I do feel there is a practical need for 
> this.
> 
> Ashley Gullen
> Scirra.com
> 
> 
> On 10 September 2012 19:14, Dean Jackson  wrote:
> I sent this to the public-h...@w3.org list:
> 
> http://www.w3.org/mid/b2fff68c-cd91-4273-8087-ec3058d24...@apple.com
> 
> Copied below.
> 
> [[[
> 
> I propose adding a new method to HTMLCanvasElement:
> 
> interface HTMLCanvasElement : HTMLElement {
>   boolean supportsContext(DOMString contextId, any... arguments);
> };
> 
> supportsContext takes the same parameters as getContext, and simply returns
> true if the corresponding call to getContext would have returned a valid
> context, false otherwise.
> 
> The justification for this method is that it is sometimes expensive to create 
> a
> context. Many authors test for a canvas feature by trying to create a context,
> examining the return value, and doing something different if the context was
> null. This is ok in most cases, but there are some instances where we don't
> want to create a context unless the page is really going to make use of it.
> 
> To give a real world example, the popular tool Modernizr tests for the
> availability of WebGL by attempting to create a WebGL context. This can happen
> even on pages that have no intention of using WebGL - an author has just
> inserted Modernizr into their page and is using it to test for another 
> feature.
> As I said, creating a context is not a free operation. In fact, on shipping
> Safari (Mountain Lion) this causes us to switch to a more powerful GPU
> on systems that have two graphics processors.
> 
> An alternative (for the WebGL case) would be to have the author test for the
> presence of window.WebGLRenderingContext. However, this is not reliable. We 
> may
> ship a browser that supports WebGL, but not on the particular hardware
> configuration that the user is running. Or it could be a momentary
> unavailability. There are a number of visible top-level WebGL apis, and we
> don't want to have to hide/show them all based on availability.
> 
> ]]]
> 
> Dean
> 
> 
> 

Re: [whatwg] [canvas] Proposal for supportsContext

[Dean Jackson]

On Sep 10, 2012, at 12:44 PM, Tobie Langel  wrote:

>>> What about enabling feature detection by providing a method per context?
>>> 
>>> interface HTMLCanvasElement : HTMLElement {
>>> object get2DContext();
>>> object getWebGLContext(any... args);
>>> };
>>> 
>>> That way, developers can use idiomatic JS for feature testing like
>>> pretty much everywhere else on the Web platform:
>>> 
>>> if (canvas.get2DContext) {
>>> // do stuff with 2D canvas
>>> }
>> 
>> This doesn't address the problem we are hitting, which is that
>> it is expensive to create a context.
> 
> It does. Only expose the API when you can create the context.

This is actually what we could do now. We could hide 
window.WebGLRenderingContext
when we can't create one. But then we'd have to hide all these too:

attribute [Conditional=WEBGL] WebGLActiveInfoConstructor 
WebGLActiveInfo;
attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer;
attribute [Conditional=WEBGL] WebGLFramebufferConstructor 
WebGLFramebuffer;
attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram;
attribute [Conditional=WEBGL] WebGLRenderbufferConstructor 
WebGLRenderbuffer;
attribute [Conditional=WEBGL] WebGLRenderingContextConstructor 
WebGLRenderingContext;
attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader;
attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor 
WebGLShaderPrecisionFormat;
attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture;
attribute [Conditional=WEBGL] WebGLUniformLocationConstructor 
WebGLUniformLocation;

It seems like a pain.

Dean

> 
>> It's also a big change to
>> an existing operational API.
> 
> Agreed. You can always leave the previous method around for backward
> compatibility.
> 
> --tobie

Re: [whatwg] [canvas] Proposal for supportsContext

[Dean Jackson]

On Sep 10, 2012, at 1:03 PM, Rick Waldron  wrote:

> 
> 
> On Mon, Sep 10, 2012 at 3:56 PM, Tobie Langel  wrote:
> > This is actually what we could do now. We could hide 
> > window.WebGLRenderingContext
> > when we can't create one. But then we'd have to hide all these too:
> >
> >attribute [Conditional=WEBGL] WebGLActiveInfoConstructor 
> > WebGLActiveInfo;
> >attribute [Conditional=WEBGL] WebGLBufferConstructor WebGLBuffer;
> >attribute [Conditional=WEBGL] WebGLFramebufferConstructor 
> > WebGLFramebuffer;
> >attribute [Conditional=WEBGL] WebGLProgramConstructor WebGLProgram;
> >attribute [Conditional=WEBGL] WebGLRenderbufferConstructor 
> > WebGLRenderbuffer;
> >attribute [Conditional=WEBGL] WebGLRenderingContextConstructor 
> > WebGLRenderingContext;
> >attribute [Conditional=WEBGL] WebGLShaderConstructor WebGLShader;
> >attribute [Conditional=WEBGL] WebGLShaderPrecisionFormatConstructor 
> > WebGLShaderPrecisionFormat;
> >attribute [Conditional=WEBGL] WebGLTextureConstructor WebGLTexture;
> >attribute [Conditional=WEBGL] WebGLUniformLocationConstructor 
> > WebGLUniformLocation;
> 
> Oh my.  All of these are globals!? *Sigh*
> 
> Has anyone considered a single global WebGL object with all of those 
> constructors defined as properties?


I'm not sure if this is getting slightly off topic. Maybe you could make that 
proposal to the WebGL working group?

Dean

Re: [whatwg] Canvas and transforms

[Dean Jackson]

On 31/12/2005, at 7:17 AM, Erik Arvidsson wrote:



Hi,

I might have missed something but why isn't there a generic  
transform method for the CanvasRederingContext2D. Currently there  
are scale, rotate and translate. Adding a generic transform might  
make a few things easier.
void translate(in float m11, in float m12, in float m21, in float  
m22);
void translate(in float m11, in float m12, in float m21, in float  
m22, in float dx, in float dy);




s/translate/transform/
and I don't think it's worth having the first method.

Otherwise +1 - very useful method (and nearly every 2d graphics API  
similar to canvas has this).


Dean



where the arguments are the numbers in the transformation matrix

  m11 m12 dx
( m21 m22 dy )
0   0  1

dx and dy are 0 when left out

--
erik

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

[Dean Jackson]

On 09/01/2013, at 4:08 PM, Dirk Schulze  wrote:

> 
> On Jan 8, 2013, at 9:35 AM, Rik Cabanier  wrote:
> 
>> I looked at pdf2js which is using this fillRule property. As I expected, 
>> introduction of the property results in code like this:
>>eoFill: function CanvasGraphics_eoFill() {
>>  var savedFillRule = this.setEOFillRule();
>>  this.fill();
>>  this.restoreFillRule(savedFillRule);
>>},
>> ...
>>// We generally keep the canvas context set for
>>// nonzero-winding, and just set evenodd for the operations
>>// that need them.
>>setEOFillRule: function CanvasGraphics_setEOFillRule() {
>>  var savedFillRule = this.ctx.mozFillRule;
>>  this.ctx.mozFillRule = 'evenodd';
>>  return savedFillRule;
>>},
>>restoreFillRule: function CanvasGraphics_restoreFillRule(rule) {
>>  this.ctx.mozFillRule = rule;
>>},
>> 
>> So, for even odd winding, all this code needs to run. With my proposal, this 
>> gets much simpler:
>>   eoFill: function CanvasGraphics_eoFill() {
>>  this.eoFill();
>>},
>> 
>> You can find a pull request with the needed changes to pdf2js here:
>> https://github.com/cabanier/pdf.js/commit/8e80b086376013a5438087714a4d2abb6fe67de1
> 
> For PDF.js it would probably be easier to set the fillRule every time right 
> before a fill or clip operation, then checking and storing the fill rule in 
> the background. This would reduce the code a lot more.
> 
>> 
>> I also created patches (with test files) for WebKit and mozilla:
>> https://bugs.webkit.org/show_bug.cgi?id=106188
>> https://bugzilla.mozilla.org/show_bug.cgi?id=827053
> 
> I looked at the patch for webkit. There are two parts where I would disagree 
> and that are potentially confusing.
> 
>   eoFill(), eoClip()
> 
> It is not obvious what these functions do and how they are different to 
> fill() and clip(). The name should be clear about the usage. But I don't 
> think that introducing two new functions to the Canvas API is a lot better 
> either. An alternative proposal instead of new functions or attributes could 
> be an optional argument for the fill() and stroke() functions. This argument 
> would be an enumeration of 'nonzero' and 'evenodd'.
> 
>   ctx.fill(); // fill with 'nonzero'
>   ctx.fill('nonzero') // fill with 'nonzero' as well
>   ctx.fill('evenodd') // fill with winding rule 'evenodd'

I prefer this approach over new methods.

In general, I tend to agree with Rik that winding rule is a geometric 
operation, rather than a context style. It's a shame that this may introduce 
inconsistency (I appreciate Ian's point on that).

Dean


> 
> The boolean argument in isPointInPath seems not to be very descriptive as 
> well: 
> 
>   boolean isPointInPath(unrestricted double x, unrestricted double y, 
> boolean windingRule);
> 
> It is not obvious if 'true' means 'nonzero' or 'evenodd'. I would recommend 
> to use an optional enumeration here, with the default value 'nonzero'.
> 
> You mentioned that the winding rule should be a part of the Path object. I 
> can see the use case that you want to address with it. And things like a 
> union path of two path object with different winding rules (as you suggested 
> before) is possible, as long as the union path just needs to get drawn (can 
> be done with compositing or masking in the implementation). But the SVG WG 
> would like to use the Path object as a way to share path data between Canvas 
> and SVG. In this case, the implementation must be able to flatten a path and 
> provide the path data directly. This is beyond the capability of current 
> graphic libraries and requires third party planarizer. This needs to be 
> considered before adding this functionality to the Path API.
> 
> Greetings,
> Dirk
> 
>> 
>> On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson  wrote:
>> On Fri, 10 Jun 2011, Chris Jones wrote:
>>> 
>>> 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.
>> 
>> I've added this to the spec.
>> 
>> 
>> On Wed, 2 Jan 2013, Dirk Schulze wrote:
>>> 
>>> There was a complain on the webkit bug report if fillRule should be part
>>> of the graphics state or not. Did you investigate what current 2d
>>> graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics
>>> state there?
>> 
>> I have made it be part of the graphics state in the spec; it would be
>> unusual in the API for it not to be. However, if this doesn't match
>> implementations, please let me know.
>> 
>> 
>> On Wed, 2 Jan 2013, Rik Cabanier wrote:
>>> 
>>> this features is not a trivial as it seems. Adding this will necessitate
>>> updates to the algorithms that deal with paths and the outlining of
>>> strokes and text.
>> 
>> Can you elaborate on what updates are needed? I couldn't see any that
>> actually needed to be changed.
>> 
>> 
>>> As Dirk mention

Re: [whatwg] Challenging canvas.supportsContext

[Dean Jackson]

On 25/06/2013, at 5:56 AM, Benoit Jacob  wrote:

> 2013/6/21 Benoit Jacob 
> 
>> Any other application use cases?
>> 
> 
> Anyone?
> 
> I believe that if no unquestionable application use case can be given, then
> this function should be removed from the spec.

I think I was the person who proposed the method, and we just implemented it
in WebKit.

I'm not going to oppose removal, but I do think it is still fairly useful. Tab
mentioned many of the things I had in mind (analogous to @supports, possibly
better described as "maybe" and "no", etc). Maybe convenient is a better word?

I don't really buy the argument that it is useless for feature detection because
even if supportsContext('webgl') returned true, you don't know if you can 
actually
use WebGL until you create a context. Obviously pages will have to be written
to support failing calls to getContext. They have to do this with or without
this API.

Also, the presence of window.WebGLRenderingContext doesn't necessarily indicate
that WebGL is supported. On iOS for example, that object is available in Safari
but calling getContext('webgl') fails. The supportsContext method would allow
authors to easily detect this case.

One could also imagine a vendor extension context type that is impossible to
detect via DOM properties, and is unable to avoid lazy instantiation.

Anyway, it seems most people want to remove it, so I'm not going to fight.

Dean

Re: [whatwg] Challenging canvas.supportsContext

[Dean Jackson]

On 25/06/2013, at 5:54 PM, Simon Pieters  wrote:

> On Mon, 24 Jun 2013 23:31:59 +0200, Dean Jackson  wrote:
> 
>> Also, the presence of window.WebGLRenderingContext doesn't necessarily 
>> indicate
>> that WebGL is supported. On iOS for example, that object is available in 
>> Safari
>> but calling getContext('webgl') fails. The supportsContext method would allow
>> authors to easily detect this case.
> 
> Since supportsContext is not supported in Safari on iOS, authors cannot use 
> it to detect this case at all.

I think you missed the point. I know it's not there, which is why we suggested 
adding it :)

> We could say in the spec that if a UA knows it cannot create a specific 
> context, it must hide the corresponding interface object. This does basically 
> the same thing as supportsContext, except that it would also work for pages 
> that already do feature detection based on the interface object.

Showing or hiding interface objects is not something I want to do. Others on 
this thread said the same thing.

Dean

Re: [whatwg] Challenging canvas.supportsContext

[Dean Jackson]

On 4 Sep 2013, at 10:47 am, Boris Zbarsky  wrote:

> On 9/3/13 7:13 PM, Ian Hickson wrote:
>> Wouldn't checking for window.WebGLRenderingContext be just as unreliable
>> then? I don't understand why it's ok to be able to test that, but why
>> probablySupportsContext() wouldn't be ok.
> 
> I'm a lot more OK with the "probablySupportsContext" naming than 
> "supportsContext" here.

I will update WebKit to probablySupportsContext asap.

Dean

Re: [whatwg] High-density canvases

[Dean Jackson]

On 10 Sep 2013, at 10:00 am, Ian Hickson  wrote:

> On Wed, 17 Jul 2013, Rik Cabanier wrote:
>> Ian wrote:
>>> 
>>> The density aspect of this might be pointless, given the failure of 
>>> getImageDataHD(); if we're dropping that one, I'll drop this one at 
>>> the same time.
>> 
>> Yes, please drop it since the HD methods are going away from the one 
>> implementation.
> 
> On Tue, 9 Jul 2013, Stephen White wrote:
>> 
>> Conversely, if it helps to bring the spec closer to the implementations, 
>> one thing we do not intend to implement in Chrome is the automatic 
>> high-DPI canvas scaling (ie., auto-doubling of backing stores, 
>> getImageDataHD(), putImageDataHD(), etc).
>> 
>> I believe Apple has also announced that they are dropping support for 
>> this in Safari 7.
> 
> So my understanding is that the reason this feature failed is that there's 
> existing content that assumes a 1:1 ratio, and having an automatic 
> high-density mode was making some pages end up with canvases with four 
> canvas pixels per CSS pixel (linearly) -- two from the browser making a 
> native canvas, times two from the page scaling the canvas for high DPI 
> displays. This is a factor of sixteen over a 1:1 canvas, a factor of four 
> more than it should be for high DPI, and a big waste of resources.

It wasn’t just that. A lot of existing code did something like this:

var pixels = ctx.getImageData(0, 0, canvas.width, canvas.height);
for (var i = 0; i < canvas.width; i++) {
  for (var j = 0; j < canvas.height; j++) {
pixels[j * canvas.width + i][0] = newRedValue;
pixels[j * canvas.width + i][1] = newGreenValue;
pixels[j * canvas.width + i][2] = newBlueValue;
  }
}
ctx.putImageData(…)

i.e. no one read the spec that says you should check the width and height
of the returned ImageData.

Then there is toDataURL(). Should that return a full-sized bitmap? Then you
need to be sure what you’re uploading it to will handle the larger size.

Basically, there was pretty unanimous support from Web developers to
“just give us the damn pixels we asked for”, as well as Chrome and Mozilla
suggesting they didn’t want to implement the auto-doubling.

We (Safari) were in a position where we were requiring developers to
write extra code just for us, as well as potentially breaking some
(existing) content.

> 
> As much as sites do this manually, though, it's a huge pain in the neck to 
> have to worry about pixel density when you're creating your canvas and 
> drawing on it, especially if you're not drawing sprites on it.
> 
> While we're talking about annoying things, there's also the annoyance that 
> canvases tend to not take zoom into account (either density-affecting zoom 
> like page zoom on desktop, or "transparent" zoom like pinch-zoom on mobile 
> for non-mobile-optimised sites, which the site isn't supposed to know 
> about): you have to remember to listen for onresize, and then manually 
> blow away your canvas and recreate it at the right density and then 
> squeeze it into place so that the coordinate space matches what your code 
> is expecting while the  is actually sized for the display.

Yes, but I think the developer is the one who best knows what size/quality
her content requires.

A great developer will do exactly as you suggest: constantly examine the
rendered size of the canvas (taking into account pixel density and 
viewport/zoom).

> 
> There's also the issue of full-bleed canvases where every time the 
> container changes, you have to remember to re-update the canvas coordinate 
> space and repaint because otherwise your pretty page gets all warped.
> 
> It would be nice to fix these all at once, and I think we can, by 
> introducing a configuration option on getContext(), in the style of WebGL:
> 
>   getContext('2d', { density: 'autosize' });
> 
> This would trigger the following behaviour: When the context is created, 
> and subsequently when the  changes size (e.g. due to being sized 
> with CSS relative units and the element they're relative to changing), or 
> when the display density changes size (e.g. due to page zoom), then:
> 
>   - the width and height of the canvas bitmaps get updated to match the
> new native size of the , at native density.
> 
>   - the coordinate space of the canvas (context.width/context.height) 
> gets updated to match the size of the  in CSS pixel units.

Note that this would reset the context, which would throw away the contents
and context state. This might be exactly what you want though - put
this attribute on a full-bleed canvas and resize your window -> everything
disappears unless you implement the ‘resize’ event handler.

> 
>   - a 'resize' event gets fired at the .
> 
> We would dump the *HD versions of the methods, and make the regular ones 
> go back to returning the actual raw pixels, since that would now work fine 
> and still provide HD-quality content everywhere it's available.
> 
> What do people think?

This seems ok to me. I still worry we’ll get

Re: [whatwg] High-density canvases

[Dean Jackson]

On 11 Sep 2013, at 5:32 am, Ian Hickson  wrote:

> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 12:14 am, Stephen White  
>> wrote:
>>> 
>>> now that some browsers are including browser zoom (page zoom) in 
>>> window.devicePixelRatio
>> 
>> Ouch. Who is doing this and why?
> 
> Why ouch?

Because we’ve always operated under the assumption that devicePixelRatio is the 
mapping from CSS px to device pixels at 1:1 scale/zoom, and that it is constant 
for a particular display. The only change content would see is if the window is 
dragged to/from a high resolution screen.

There are other ways to query the page zoom.

I fear this will break existing content. I don’t think we’d ever want to change 
the behaviour.

Dean

> 
> Actually what I really think we should do is also change the 
> window.devicePixelRatio for pinch zoom. Combined with the suggestions for 
> canvas, that would allow (as Rik pointed out on IRC) for high-quality 
> canvas all the way zoomed in, and for cheap canvases when zoomed out.

Re: [whatwg] High-density canvases

[Dean Jackson]

On 11 Sep 2013, at 6:13 am, Ian Hickson  wrote:

> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 5:32 am, Ian Hickson  wrote:
>>> On Wed, 11 Sep 2013, Dean Jackson wrote:
>>>> On 11 Sep 2013, at 12:14 am, Stephen White  
>>>> wrote:
>>>>> 
>>>>> now that some browsers are including browser zoom (page zoom) in 
>>>>> window.devicePixelRatio
>>>> 
>>>> Ouch. Who is doing this and why?
>>> 
>>> Why ouch?
>> 
>> Because we’ve always operated under the assumption that devicePixelRatio 
>> is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that 
>> it is constant for a particular display. The only change content would 
>> see is if the window is dragged to/from a high resolution screen.
>> 
>> There are other ways to query the page zoom.
> 
> That seems broken... why would you want to hide the page zoom?

We don’t want to hide page zoom.

I think there are two separate things a developer might want:

- the number of actual pixels that correspond to 1 CSS px without zoom
- the page zoom

If you merge the two, then an unsuspecting developer might think that the user 
has zoomed in by 2x on an iPhone, and decide to make things smaller. Yes, 
that’s not necessarily great content, but it makes some sense. For most page 
content you don’t really care about the device:pixel ratio - text looks fine! 
For images, you should use the mechanisms we’ve developed (srcset and 
image-set).

Now, I completely agree that there are going to be cases where you might want 
the image selected for srcset and image-set to respond to zoom. After all, 
there is no point loading a huge image if it is going to be 1x1 cm^2. But I 
think that’s separate from changing devicePixelRatio.

>> I fear this will break existing content. I don’t think we’d ever want to 
>> change the behaviour.
> 
> I guess we'll just have to treat devicePixelRatio as legacy and introduce 
> a new value that's the real device:pixel ratio, then.

Indeed. I’m not opposed to exposing this. I am reluctant to change something 
that has behaved a particular way for a number of years.

Meanwhile, back to canvas, why don’t we change canvas to be purely callback 
based, and pass in all the info a developer needs to decide what the best 
output should be? Put something like requestAnimationFrame into the canvas spec 
(although that is a bad name - it only sometimes is related to animation). That 
way you could even imagine a future where a single canvas could have multiple 
render targets (when printing you get an even higher resolution).

Dean

Re: [whatwg] High-density canvases

[Dean Jackson]

On 11 Sep 2013, at 12:14 am, Stephen White  wrote:

> now that some browsers are including browser zoom (page zoom) in 
> window.devicePixelRatio

Ouch. Who is doing this and why?

Dean

Re: [whatwg] High-density canvases

[Dean Jackson]

On 11 Sep 2013, at 3:20 am, Robert O'Callahan  wrote:

> On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier  wrote:
> There's a thread on www-style:
> http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html
> It's been in firefox for a while and blink is going to ship it soon:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi3zdumQ
> 
> devicePixelRatio has reflected page zoom in Firefox ever since we first 
> exposed it (because the thing it maps to internally has always been affected 
> by page zoom).

OK. I can accept that it makes sense for page zoom (I was only thinking about 
pinch zoom... which is a bad name). Still, we've (Apple) been telling 
developers for a long time that devicePixelRatio is (basically) constant. I 
guess we'll have to either change or be non-conformant.

>  
> > > Actually what I really think we should do is also change the
> > > window.devicePixelRatio for pinch zoom. Combined with the suggestions for
> > > canvas, that would allow (as Rik pointed out on IRC) for high-quality
> > > canvas all the way zoomed in, and for cheap canvases when zoomed out
> 
> I believe pinch zoom should not change devicePixelRatio. It would be nice
> if there was a standard way to determine pinch zoom though and if the
> canvas could automatically resize.
> 
> Pinch-zoom is hard because we don't want to trigger reflows or other 
> expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for now.

Agreed.

Dean

Re: [whatwg] Questions regarding Path object

[Dean Jackson]

On 17 Oct 2013, at 9:20 am, Ian Hickson  wrote:

>> PS: iOS 7 is barely released, but the first bug reports are already 
>> coming in, because the new Mobile Safari now defines Path, and clashes:
>> 
>> https://twitter.com/danetag/status/380636739251220480
> 
> Looks like this user solved the problem pretty quickly.
> 
> I tried to find more evidence of problems now that iOS7 is out with this, 
> but I'm not finding much. (I did a bunch of searches on Google.) 
> 
> Having said that, I'm not saying there's no conflicts. If Chrome and 
> Safari want to change to a different name, we can definitely still do 
> that, it's early days yet. DOMPath, maybe? Or Path2D, or CanvasPath.
> 
> Still, on the long term it'd be sad that we can't just use Path.

FWIW, many new specifications are hitting issues like this (well…
at least Web Animations!). It’s a pain that new classes can
clash with existing content, but I think we have to act
as if the future is bigger than the past and thus pick the best
name for the job.

As someone else said, the rule of not injecting into the global
namespace from a JS library has been known for a few years now,
and if you’re still not doing it you’re asking for trouble.

Dean

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

[Dean Jackson]

FWIW - I think that
ctx.currentPath != ctx.currentPath
is a horrible mistake and we should fix WebKit.

Dean

On 4 Nov 2013, at 2:47 pm, Rik Cabanier  wrote:

> On Mon, Nov 4, 2013 at 11:25 AM, Rik Cabanier  wrote:
> 
>> 
>> 
>> 
>> On Mon, Nov 4, 2013 at 1:49 AM, Jürg Lehni  wrote:
>> 
 What's the use case?
 
 I intentionally didn't add this to the spec when I was adding the last
>>> set
 of path-related features, because it seems entirely redundant with Path
 objects. I thought we'd want people to move away from using the implicit
 path, rather than making it more powerful.
>>> 
>>> I like this feature a lot. One advantage to not underestimate is the
>>> amount of effort it takes to change existing code to make use off the new
>>> Path feature, while staying backward compatible with older browsers that
>>> don't implement this spec. For example, in Paper.js it took only three
>>> added lines of code to use cached paths if they exist rather than redrawing
>>> them each time
>>> 
>> 
>> Do you think getCurrentPath should return a path in user space or in the
>> current transformation matrix?
>> 
> 
> Answering my own question, when reading the canvas spec [1], it should be
> in user space:
> 
> When the intended path is a
> Path
> object,
> the coordinates and lines of its subpaths must be transformed according to
> the 
> CanvasRenderingContext2D
> object's current transformation
> matrix
> when
> used by these methods (without affecting the
> Path
> object
> itself). When the intended path is the current default
> path,
> it is not affected by the transform. (*This is because transformations
> already affect the **current default
> path**
> when
> it is constructed, so applying it when it is painted as well would result
> in a double transformation*.)
> 
> 
> In light of this, does anyone have objections to these 2 new methods:
> 
> Path getCurrentPath();
> 
> void setCurrentPath(Path);
> 
> 
> With the path in user space (so it is not affected by the CTM).
> 
> 1:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-paths-to-the-canvas

Re: [whatwg] High-density canvases

[Dean Jackson]

> On 20 Jun 2014, at 12:54 am, Stephen White  wrote:
> 
> On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan  
> wrote:
> I think I'd rather not take control of canvas resizing away from 
> applications, even opt-in. That leads to complexity such as extra API for 
> slaving other canvases. I also think we'd be better off sticking to the 
> invariant that the units of canvas coordinate space are single pixels in the 
> canvas bitmap; I think that simplifies things for implementers and authors.
> 
> I agree.

+1 from me too and for the rest of Robert's proposal.

Dean

[whatwg] "resize" events on elements

[Dean Jackson]

At the recent Houdini meeting there was a vague agreement between the browser 
engines on adding a way for elements to be notified when their size changes. 
We've run into a number of scenarios where this is extremely useful, and is 
otherwise difficult or annoying (e.g. checking your size on a timer).

The idea was to allow the resize event on elements. I don't really care what 
the solution is, so maybe someone here can come up with a better idea (size 
observers?). And of course there are a lot of details to be worked out.

If we settle on a solution fairly soon I will implement it in WebKit nightly 
builds so people can play.

Dean

Re: [whatwg] "resize" events on elements

[Dean Jackson]

> On 24 Feb 2015, at 6:32 pm, Anne van Kesteren  wrote:
> 
> On Tue, Feb 24, 2015 at 2:40 AM, Dean Jackson  wrote:
>> The idea was to allow the resize event on elements. I don't really care what 
>> the solution is, so maybe someone here can come up with a better idea (size 
>> observers?). And of course there are a lot of details to be worked out.
> 
> It seems this should be defined by the CSS WG, no? None of the
> standards WHATWG publishes have much bearing on when an element
> resizes so there's no place to put "fire a resize event". I'd expect
> that somewhere within a layout standard.

That's a good point, and I'm happy to keep it in CSS. The reason
I sent the request here is because I figured HTML was the place
that had the existing 'resize' event (for ... although maybe
it doesn't - I've never read the HTML spec :)

> 
> The only change I would expect here is a change to HTML to make sure
> such an event can be animation frame synchronized.

OK. We'll send an update if we think HTML needs to change.

Dean

Re: [whatwg] High-density canvases

[Dean Jackson]

> On 16 Apr 2015, at 6:42 am, Elliott Sprehn  wrote:
> 
> 3. Accessing rendered pixel size is layout-inducing. To avoid layout
> thrashing, we should consider making this an asynchronous getter (e.g.
> asyncGetBoundignClientRect). This would also prevent renderedsizechanged
> events from firing from within the evaluation of the renderedPixelWidth/Height
> attributes, which is weird.
> 
> renderedsizechanged feels like it's related to the general per element resize 
> event problem. It'd be unfortunate to add an event to the browser 
> specifically for canvas instead of solving the general problem. In that case 
> authors will start resorting to hacks where they insert canvases into the 
> page to listen for resizes (we've seen this with other events like 
> overflowchanged).
> 
> Perhaps we should add per element resize events and spec that they fire after 
> the layout, but before the paint, during normal frame creation. That does 
> mean you can cause an infinite loop if your resize handler keeps mutating the 
> page, but there's so many other ways to cause that already.

+1

Dean