- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 03 Aug 2007 20:37:56 -0700
- To: Philip Taylor <philip@zaynar.demon.co.uk>, public-html@w3.org
----- Original Message ----- From: "Philip Taylor" <philip@zaynar.demon.co.uk> To: <public-html@w3.org> Sent: Friday, August 03, 2007 7:12 PM Subject: The canvas element (detailed review) > drawImage: > > "The image argument must be an instance of an HTMLImageElement or > HTMLCanvasElement. If the image is of the wrong type, the implementation > must raise a TYPE_MISMATCH_ERR exception." - what if it is the correct > type but null? (The same applies to createPattern). (Currently, FF > throws NS_ERROR_NOT_AVAILABLE, Opera throws TYPE_MISMATCH_ERR, Safari > crashes.) > 'null' is a value of empty object reference. No object - no type. So "is the correct type but null" is a bit confusing. > What should happen if sw = 0 or sh = 0? (Firefox draws nothing, Opera > (9.2) draws something (top left pixel?), Safari 3 throws INDEX_SIZE_ERR.) It should draw nothing - zero dimension is zero dimension. Another interesting question is what should happen when sw, sh are negative. Say if sh < 0 shall image be drawn as mirrored? > > What should happen if the image is animated? (Firefox and Safari draw > the current frame. Opera draws nothing). Similar issue with > createPattern. (In that case, Firefox 2 and Safari always draws the same > frame as was first drawn; Firefox 3 randomly (each time you reload the > page) either does the same as FF2 or else uses the current animation > frame each time it draws something with the pattern; Opera returns > undefined from createPattern.) I think "unspecified" so "up to implementation" is just enough. There are various methods of how to render animation. In general rendering of current frame makes no sense for GIFs. > > It might be nice to say "Implementations should use bilinear filtering > when resizing the image", so that implementations agree with each other > except when they have reasons not to (e.g. resource constraints which > make bilinear filtering too expensive). (At least, I think current > implementations are doing bilinear filtering - is that correct?) It should be either "unspecified" or CanvasRenderingContext2D should have attribute of type enum ImageFilter { NoFilter, Bilinear, Hanning, Hermite, Quadratic, Bicubic, Catrom, Spline16, Spline36, Blackman144, ... } that would allow to select proper method. Currently 'unspecified' UA may select proper method heuristically. > > It's not explicit that the transformation applies only to the > destination rectangle, and not the source rectangle. It needs to be specified that sx, sy, sw and sh are in "device units" of the image so, yes, destination coordinate system is irrelevant. Andrew Fedoniouk. http://terrainformatica.com
Received on Saturday, 4 August 2007 03:40:38 UTC