Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients

2011-06-26 Thread Aryeh Gregor
On Fri, Jun 24, 2011 at 10:52 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
 That's true if you call fillRect(), or fill() on a path that you've emitted
 while the current matrix is singular; the rectangle or path collapses to a
 single point (or line). I think it's completely clear browsers should draw
 nothing in those cases.

 However, my testcase emits a path while the matrix is non-singular, so the
 canvas-space path is definitely not collapsed to a point or line, then makes
 the matrix singular just for the fill operation. The question is then how
 the singular matrix affects the way the source color, gradient or pattern
 fills a non-empty path.

I'm thinking of the source color, gradient, or pattern conceptually
filling the plane (possibly almost all transparent in the case of a
pattern), then being transformed by the matrix, then being clipped to
fill the shape before being painted.  Thus in my mind it's still being
collapsed before being painted, even if it's just a solid color.  That
way a solid color is conceptually the same as a gradient with all
color stops the same, or a solid-colored image.

It seems like a useful invariant if the different styles behave the
same reliably when they should logically be the same.  That way
authors can learn about patterns first (which is very concrete --
give it an image), then understand gradients and solid colors as
special cases of patterns, and be consistently right.  Authors might
be surprised by the behavior in this particular case, but it's a
fairly pathological case anyway, and it doesn't seem worthwhile to
trade away consistency to get more intuitive behavior in this special
case.

I guess one big problem with this approach is you have a singularity
at determinant zero, and that's really awkward because you can't rely
on floating-point equality comparisons unless you allow some tolerance
for rounding error, and in that case equality is no longer transitive.
 By my theory, a transformation matrix with determinant zero should
result in solid colors doing nothing, but one with determinant e for
any e  0 should result in the color being painted.  This is obviously
bad.

So this is probably my pure math background showing through rather
than a very useful contribution to the discussion.  If the API were
designed for mathematicians, now . . .

On Fri, Jun 24, 2011 at 11:00 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
 If you set up a path covering the entire canvas, call ctx.scale(e, e) for
 infinitesimal e, and then fill with an image pattern, conceptually you're
 scaling the image to be incredibly small and then repeating it a very large
 number of times to fill the canvas. So I guess the logical behavior for e=0
 would be to compute the average color of the image pixels and do a solid
 fill with that color, which would give you that consistency you're asking
 for. But is that worth implementing? No-one does that today.

What does everyone do today instead?  I'm guessing canvas doesn't
currently define how you should apply the transformation matrix
precisely, and in particular how to handle cases like this with
subpixel detail.  The same issue should arise for gradients with very
small stops (as Tab points out), or ones with large stops that are
scaled down a lot.

If e were exactly zero, though, the logical behavior in my
interpretation would be to paint nothing for any operation whatsoever,
since the determinant is zero.  But again, that's problematic.


Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients

2011-06-26 Thread Boris Zbarsky

On 6/26/11 6:14 PM, Aryeh Gregor wrote:

So this is probably my pure math background showing through rather
than a very useful contribution to the discussion.  If the API were
designed for mathematicians, now . . .


The argument could still be made that we want behavior to be continuous

-Boris



Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients

2011-06-26 Thread Robert O'Callahan
Gradients already aren't continuous where the start and end points are
equal. I think it would be OK to draw nothing as Aryeh suggests. At least
it's easy to spec and implement, and I doubt authors will care (they haven't
cared about the browser behaviors so far AFAIK).


Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients

2011-06-26 Thread Boris Zbarsky

On 6/26/11 8:18 PM, Robert O'Callahan wrote:

Gradients already aren't continuous where the start and end points are
equal. I think it would be OK to draw nothing as Aryeh suggests. At
least it's easy to spec and implement, and I doubt authors will care
(they haven't cared about the browser behaviors so far AFAIK).


OK, fair.  Do we think float round-off errors won't bite us much here?

-Boris




Re: [whatwg] canvas drawing with singular transforms and zero-sized gradients

2011-06-26 Thread Robert O'Callahan
On Mon, Jun 27, 2011 at 2:11 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 6/26/11 8:18 PM, Robert O'Callahan wrote:

 Gradients already aren't continuous where the start and end points are
 equal. I think it would be OK to draw nothing as Aryeh suggests. At
 least it's easy to spec and implement, and I doubt authors will care
 (they haven't cared about the browser behaviors so far AFAIK).


 OK, fair.  Do we think float round-off errors won't bite us much here?


No more than they would for other discontinuous cases like gradients with
equal start and end points.

Rob
-- 
If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us. [1 John 1:8-10]


[whatwg] A web standards based model for Augmented Reality

2011-06-26 Thread Rob Manson
Hi,

my name is Rob Manson and I'm one of the co-founders of
http://ARStandards.org and an Invited Expert on the W3C Points of
Interest Working Group http://www.w3.org/2010/POI/

I've recently published an outline for a web standards based model for
AR that is obviously closely related to all the work going on at the
whatwg.  So I thought I'd send this off to this list looking for
feedback and constructive criticism.

http://robman.com.au/a-web-standards-based-model-for-ar-in

Obviously some of the test elements are based on APIs that are still
forming or are not yet widely adopted.  I'm ok with that 8)

In fact I'm hoping that by raising this as a big hairy audacious goal
that we can use it as a thought experiment to validate some of the plans
for these APIs as they evolve (e.g Audio Data vs Web Audio and WebRTC).

I think the functional needs for AR are very clear and they introduce
some unique and exciting new use cases for API developers to take into
account.

So, I'd really appreciate any comments you have...both positive and
negative.  Currently we're working on breaking each of the test elements
out into wiki pages so people can contribute to the discussion and
development of each of these.  We'll also put the test onto github, etc.
too.

We're also looking for some great demos to include.  We need a
multitouch friendly js game if you know of one.  And the gyro and motion
examples obviously haven't been plugged in yet.  Plus none of the
browsers in the wild really support the required audio and video APIs
yet.

I'll look forward to hearing what you think...


roBman



[whatwg] multiple itemtypes in microdata?

2011-06-26 Thread John Giannandrea
In the user feedback from the schema.org proposal, which uses microdata as
its syntax, we have seen several use cases that would seem to require
multiple itemtypes per itemscope.

Currently the microdata spec only allows one itemtype which defines the
meaning of the vocabulary for subsequent itemprops.

Allowing an arbitrary list of itemtypes would not be desirable because then
a user agent would have to have knowledge of the type vocabularies in order
to parse the page.

We suggest that itemtype be changed to allow multiple space separated types
(just like itemprop), but only if the origin domain of the types is the
same.  This would allow a vocabulary provider to allow multiple types and to
take responsibility for what the property vocabulary definition is in the
context of more than one type.

-jg