[Bug 10799] New: drawImage/pattern filters underspecified

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10799

           Summary: drawImage/pattern filters underspecified
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML Canvas 2D Context (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: vladimir@pobox.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Created attachment 915
  --> http://www.w3.org/Bugs/Public/attachment.cgi?id=915
testcase

This came from mozilla bugzilla bug
https://bugzilla.mozilla.org/show_bug.cgi?id=600390.  The canvas spec doesn't
really say anything about filters, and especially how they apply to
drawImage/patterns.

The attached testcase demonstrates the problem -- it doesn't render identically
on any of the canvas-implementing browsers (firefox, opera, chrome, ie9 --
don't have safari handy to test).

The two sets in the testcase are using a canvas as a source and using an image,
both with the same contents; usually there's no difference between the two. 
The large squares are, from left to right:

1) straight drawImage 0,0,60,60 -> 0,0,300,300
2) stairstepped drawImage, doing 2 draws per horizontal band
3) stairstepped fill() using a no-repeat pattern source
4) 300x300 rectangle fill, but with source offset by 150,150
5) same as #4, but rotated as well to examine antialiasing effects

I -think- Firefox renders it the most "correctly", even though it's almost
never what you want; but mathematically it's correct, and it causes the least
change when under transforms -- with no repeat, the area outside of the
source's defined bounds is transparent black; so at edge pixels when scaling
up, when you sample acros that boundary, you get half of the transition between
transparent black and the edge color.

IE9 renders "what I want", but it's also the most difficult to specify
precisely.  Opera also gets close, except all their paths are offset by 5
pixels for some reason.

Chrome is quite bad here, because I think it's trying to be smart about using
the source rect for drawImage as a standalone image in its own right -- this
causes problems if you, for example, try to draw a scaled-up image piecemeal,
as you'll get seams.  It also uses pad/clamp behaviour for a pattern that's
specified as no-repeat -- however, the spec doesn't actually define no-repeat,
so their interpretation is as good as any other.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 29 September 2010 03:57:15 UTC