Re: [whatwg] <canvas> feedback

On Mon, Apr 7, 2014 at 6:35 PM, Ian Hickson <ian@hixie.ch> wrote:

>
>
> > For example, there is no locale for font family resolution
>
> I'm not clear on what you mean by "locale" here. What is the locale that a
> displayed <canvas> in a Document in a browsing context has, that a
> non-displayed <canvas> outside a Document and without a browsing context
> does not have?
>

I am not sure exactly how this relates to the specification, but when
reading the code in Blink, I saw that font family resolution goes through
different paths if the view has a Korean, Chinese or Japanese locale.  Some
OSes allow you to have different locales on a per window basis, so you need
to have a view (i.e. a browsing context) associated with the Document in
order to resolve this.


> > and it is not possible to resolve font sizes in physical length units
> > unless the document is associated with a view.
>
> Why not? The canvas has a pixel density (currently always 1:1), no?
>

1:1 is not a physical pixel density. To resolve a font size that is
specified in physical units (e.g. millimeters or inches) you need something
like a DPI value, which requires information about the output device.

>
> > My 2 cents: specifying fallback behaviors for all use cases that are
> > context dependent could be tedious and I have yet to see a real-world
> > use case that requires being able to paint a canvas in a frame-less
> > document. Therefore, I think the spec should clearly state <canvas>
> > elements that are in a document without a browsing context are unusable.
> > Not sure what the exact behavior should be though.  Should an exception
> > be thrown upon trying to use the rendering context? Perhaps canvas draws
> > should fail silently, and using the canvas as an image source should
> > give transparent black pixels?
>
> As far as I can tell, this is all already specified, and it just gets
> treated like a normal canvas.
>

Agreed. The fallback behavior is specified. But is it good enough? There
will be discrepancies, sometimes large ones, between text rendered with and
without a browsing context.

On Wed, 5 Mar 2014, Rik Cabanier wrote:
> >
> > Testing all browsers (except IE since
> > document.implementation.createHTMLDocument() doesn't work) they seem to
> > handle canvas contexts with no browsing context except when you use
> > text. Chrome crashes, firefox throws an exception and Safari draws the
> > text with a very small scale
>
> I don't really understand why this is problematic in practice. What does a
> browsing context provide that is needed for rendering text that a user
> agent couldn't fake for itself in other contexts? We're definitely going
> to need text in worker canvases.
>

It is because the browsing context serves as a bridge between the document
and the OS/window manager/display device. Therefore some of the system
configuration info that comes into play in font style resolution and text
rendering is not accessible when the document is not associated with a
browsing context. For example to know which locale to use, the document
needs to be linked to a window; to know the display density (dpi) we need
to know which display device will be used for displaying the document; to
use subpixel text anti-aliasing, we need to know the display device's LCD
configuration; etc. If we fake this information by using fallbacks and
defaults, we may end up with text that looks different when rendering in a
Worker or into a Document without a browsing context. If we want everything
to look the same, perhaps the spec should specify how to get to a browsing
context that can be used for retrieving display settings. For example, if
the current document has no browsing context, use the settings from the
browsing context of the global 'document' object.  That would probably
match the developer's intent almost all the time.


>
> On Fri, 14 Mar 2014, Justin Novosad wrote:
> > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian@hixie.ch> wrote:
> > >
> > > If the bug is that Chrome resamples the image in an ugly way, then
> > > that's a bug with Chrome. As the bug says, browsers are allowed to
> > > pick whatever algorithm they want -- it's a quality-of-implementation
> > > issue. But if the result is ugly, that's a low quality implementation.
> >
> > Yes, and if we fixed it to make it prettier, people would complain about
> > a performance regression. It is impossible to make everyone happy right
> > now. Would be nice to have some kind of speed versus quality hint.
>
> The problem with a hint is that it will be set incorrectly, and so instead
> of having something that's mostly pretty but mostly fast for everyone,
> you'd end up with something that's slow on sites that need things to be
> fast, and things that are ugly on sites that need things to be pretty.
>
> In general I think it is very unwise for us to design APIs with hints that
> have subtle effects on developer machines but that can cripple performance
> on low-end devices.
>

The point of it being a hint is that the UA is free to disregarded it
precisely in that
kind of situation (e.g. fallback to fastest filtering on a low-end device)


> Instead, we should use adaptive algorithms, for example always using the
> prettiest algorithms unless we find that frame rate is suffering, and then
> stepping down to faster algorithms.
>

Such an adaptive algorithm implies making some kind of weighted decision to
chose
a reasonable compromise between quality and performance.  Sounds like the
perfect place to use a hint.


>
>
> On Mon, 17 Mar 2014, Justin Novosad wrote:
> >
> > Yes, but there is still an issue that causes problems in Blink/WebKit:
> > because the canvas rendering context stores its path in local
> > (untransformed) space, whenever the CTM changes, the path needs to be
> > transformed to follow the new local spcae.  This transform requires the
> CTM
> > to be invertible. So now webkit and blink have a bug that causes all
> > previously recorded parts of the current path to be discarded when the
> CTM
> > becomes non-invertible (even if it is only temporarily non-invertible,
> even
> > if the current path is not even touched while the matrix is
> > non-invertible). I have a fix in flight that fixes that problem in Blink
> by
> > storing the current path in transformed coordinates instead. I've had the
> > fix on the back burner pending the outcome of this thread.
>
> Indeed. It's possible to pick implementation strategies that just can't be
> compliant; we shouldn't change the spec every time any implementor happens
> to make that kind of mistake, IMHO.
>
> (Of course the better long-term solution here is the Path objects, which
> are transform-agnostic during building.)
>
>
> Just to be clear, we should support this because otherwise the results are
> just wrong. For example, here some browsers currently show a straight line
> in the default state, and this causes the animation to look ugly in the
> transition from the first frame to the secord frame (hover over the yellow
> to begin the transition):
>
>    http://junkyard.damowmow.com/538
>
> Contrast this to the equivalent code with the transforms explicitly
> multiplied into the coordinates:
>
>    http://junkyard.damowmow.com/539
>
> I don't see why we would want these to be different. From the author's
> perspective, they're identical.


If we stick to that, there are still some behaviors that need to resolved.
One issue that comes to mind is what happens if stroke or fill are called
while the CTM is non-invertible? To be more precise, how would the styles
be mapped?  If the fillStyle is collapsed to a point, does that mean the
path gets filled in transparent black?  If we go down this road, we will
likely uncover more questions of this nature.


> On Tue, 25 Mar 2014, Justin Novosad wrote:
> >
> > I prepared a code change to that effect, but then there was talk of
> > changing the spec to skip path primitives when the CTM is not
> > invertible, which I think is a good idea. It would avoid a lot of
> > needless hoop jumping on the implementation side for supporting weird
> > edge cases that have little practical usefulness.
>
> I'm not sure I agree that they have little practical usefulness. Zeros
> often occur at the edges of transitions, and if we changed the spec then
> these transitions would require all the special-case code to go in author
> code instead of implementor code.
>

Yes, I think that may be the strongest argument so far in this discussion.
The examples you provided earlier illustrate it well.
I would like to hear what Rik and Dirk think about this now.

Received on Tuesday, 8 April 2014 19:25:33 UTC