Re: [whatwg] Canvas normalize rect() and strokeRect()

On Mon, Apr 7, 2014 at 10:47 AM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Mon, Apr 7, 2014 at 7:29 AM, Justin Novosad <junov@google.com> wrote:
>
>> Putting myself the the web devs shoes...  If I negate the height of a
>> rect, what would I expect?  My first though: a horizontally flipped mirror
>> image of the rect.
>>
>> Now, what does the spec say?
>> a) rect(): respect the flipped vertex order
>>
>
> yes, except it doesn't explicitly say "in that order" so a UA could
> implement it in a different one.
>

Okay. Nonetheless the spec already does define the order, it just does not
insist that it must be respected.

>
>

>
>> b) strokeRect(): respect the flipped vertex order
>> c) fillRect(): unaffected by vertex order.
>>
>
> Where do you see that fillRect is not affected?
>

It does not say so explicitly, but it is implied. The coloring of pixels is
governed by the fillStyle, which is not affected vertex order.


>
>> d) fillStyle and strokeStyle style application is independent of the
>> primitive, mapping is controlled by CTM (and a pattern matrix)
>>
>> I find the spec is consistent with itself as it is currently worded.  If
>> you want to flip a rect (or any other geometry for that matter), you can
>> either flip everything together using the CTM, or flip its parts (the
>> vertices and the styles) individually.
>> I think that having the styles automatically flip when the rect is
>> inverted would have an undesirable consequence: It would break consistency
>> with path rendering (how do you define the notion inverted geometry for a
>> general, possibly self-intersecting, path?)
>>
>
> I'm unsure why we would switch geometry. Are you referring to the dashing?
>

Dashing is one thing that would be affected.  I think some implementations
are currently in a non-compliant state probably because the line dashing
feature was added recently.  Back when strokeRect was originally
implemented, we could get away with blindly normalizing rectangles because
there was no impact on the rendering result.  The other thing that is
affected is fill rule application.  For example, if you have a path that
contains two intersecting rectangles and you are filling in with the
nonzero rule.  If one of the two rectangles is flipped, then the
intersection region should be unfilled.  If the rectangles are "normalized"
internally by the implementation, then you will get the wrong (non spec
compliant) result.


>
>
>> On Sun, Apr 6, 2014 at 3:04 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>
>>>
>>> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>>>
>>> >
>>> >
>>> >
>>> > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze@adobe.com>
>>> wrote:
>>> >
>>> > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>>> >
>>> > >
>>> > >
>>> > >
>>> > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze@adobe.com>
>>> wrote:
>>> > > Hi,
>>> > >
>>> > > I looked at the behavior of negative width or height for the rect()
>>> and strokeRect() functions.
>>> > >
>>> > > All browsers normalize the passed parameters for strokeRect() to
>>> have positive width and height.
>>> > >
>>> > > strokeRect(90,10,-80,80) —> strokeRect(10,10,80,80)
>>> > >
>>> > > http://jsfiddle.net/za945/
>>> > >
>>> > >> It also seems that only firefox is following the spec [1] when
>>> width or height are 0: http://jsfiddle.net/za945/2/
>>> > >> I'm unsure why such a rectangle is defined as a straight line.
>>> >
>>> > You mean you would rather let it draw a one dimensional rectangle? So
>>> for the dimension that is not zero, you would see two overlapping lines +
>>> the 0 dimensional sides?
>>> >
>>> > yes
>>> >
>>> > That seems indeed to be the case for IE, Safari and Blink:
>>> http://jsfiddle.net/Gh9XK/
>>> >
>>> > >
>>> > > Just WebKit seems to normalize for rect() as well:
>>> > >
>>> > > http://jsfiddle.net/VT4MG/
>>> > >
>>> > > The behavior of normalizing is not specified. Especially it seems
>>> odd that the behavior for fillRect()/strokeRect() should differ from
>>> rect(). So we should either normalize for all functions or don’t do it for
>>> all IMO.
>>> > >
>>> > > Note: fillRect() and clearRect() are not affected. The behavior for
>>> rect() is important for filling with different winding rules as well. It is
>>> not just stroking with dash arrays that is effected.
>>> > >
>>> > >> yes, the spec needs to say "in that order" as it does for fillRect
>>> and strokeRect.
>>> >
>>> > Ok, that means you would be in favor not to normalize. Again, all
>>> current browser normalize and do NOT draw “in that order” for fillRect()
>>> and strokeRect(). That means you would require to give up the currently
>>> interoperable behavior.
>>> >
>>> > I changed your test a bit so you can more easily see the
>>> normalisation: http://jsfiddle.net/za945/3/
>>> > Safari and Chrome are doing as you say, but Firefox does not. (I don't
>>> have IE to test)
>>>
>>> Firefox has a strange different behavior if dash >= gap. If the gap is
>>> smaller it behaves like IE, Blink and WebKit. This also answers your
>>> question: Your example renders in IE the same as in WebKit and Blink.
>>>
>>> Greetings,
>>> Dirk
>>>
>>> >
>>> > I would be in favor to change the blink/webkit behavior as the
>>> specified one makes more sense.
>>>
>>>
>>
>

Received on Monday, 7 April 2014 16:00:55 UTC