On 25/09/2007, at 1:26 PM, Vladimir Vukicevic wrote:
Hi,
Oliver Hunt wrote:
Hi All,
We've encountered a number of website compatibility issues in
WebKit due to our adherence to the new Canvas specifications -- a
good example of this is rect drawing at http://canvaspaint.org
The most obvious issues can be shown if you use the draw rect tool
and resize the rect repeatedly.
The first problem is the repeated drawing of old rects, this is
due to the context path not being cleared by draw rect and fill
rect which is the behaviour present in Safari 2 and Firefox 2.
While I've discussed the issue with Hixie in the past (and to an
extent agree with him) the Firefox 3 nightlies do not appear to
have adopted this behaviour, leaving us in a position where we
have to choose between compatibility and compliance which is awkward.
For Firefox 3, there is a patch in our bugzilla, at https://
bugzilla.mozilla.org/show_bug.cgi?id=296904 that could fix this
issue -- that is, strokeRect/fillRect/drawImage would no longer
reset the current path. However, I'm confused by your comment --
Firefox 2 and current Firefox 3 trunk's behaviour is identical, as
far as I know; that is, the current path is being reset on
strokeRect/fillRect. (Did you mean "due to the context path being
cleared ..."?)
Given that this is somewhat of an edge case, would it make sense to
alter the spec here?
Firefox 2/3 and Safari 2 clear the context's path on strokeRect/
fillRect, this violates the spec -- but there are many websites that
now rely on such behaviour despite the behaviour defined in hmtl5.
This means that those browsers that match the current draft (eg.
Safari 3 and Opera 9.x) fail to render these websites "correctly".
Ideally there would be a distinct Path object, that was separate from
the canvas context but we can't have everything :D
Unfortunately it isn't really an edge case as it's a relatively
common occurance -- people expect that the rect drawing function (for
example) will clear the path, so expect clearRect
(myCanvasElement.width, myCanvasElement.height) to clear the rect and
reset the path, and other similarly exciting things :-/
I agree that throwing an exception is probably unnecessary, as
there are very few other places in the API where such exceptions
are thrown (except when the input is of clearly the wrong type).
Normalizing seems to be the most useful approach -- that is, the
functions that take x,y,w,h would be defined to create a rectangle
with its two corners being (x,y) and (x+w,y+h), regardless of the
sign of w/h, but I would be ok with making such rectangles also be
ignored. It's also fairly easy for authors to implement their own
versions of strokeRect/fillRect with any of these semantics (well,
harder if they were to preserve the current path). This is less of
an edge case than the previous issue, IMO, so we should try to
figure out what the most useful (and most straightforward) thing is
to happen here.
I agree, throwing an exception in this case seems abhorrent and not
in keeping with the behaviour of other portions of the canvas api. I
quick study would indicate that those websites that assume negative
dimensions will work seem to expect normalisation rather than
culling, so in the interests of compatibility that is probably the
best approach of the available options.
I think that it would be important to ship compatible canvas
implementations in the next versions of Firefox, Safari, and Opera;
so if we have to break existing users to do so, I hope that they
will forgive us for the compliance bumps and put in workarounds
(e.g., to call beginPath() after every strokeRect/fillRect), but it
would be better if we could avoid having to do that.
Agreed. In the latter case this seems trivial as almost anything
other than throwing an exception seems to be a technical improvement
and the alternatives (including retaining old behaviour) all seem
equally reasonable. In the case of the former i'm not sure what the
best solution is, i think that resetting the path only on beginPath()
seems to be a much more sensible behaviour, but that does clash with
a reasonable number of existing sites :(
- Vlad
--Oliver
