[whatwg] Canvas draw quality

[Andrew Fedoniouk]

>> At least something generic like preference=quality/speed switch makes
>> real sense.
>
> I would imagine that most people would rather implementations were both
> fast and had high quality all the time.
>

Yeah! You forgot to add "and free of charge" and it will be perfect 
definition
of permanent dream of mankind.

Andrew Fedoniouk.
http://terrainformatica.com



----- Original Message ----- 
From: "Ian Hickson" <ian at hixie.ch>
To: "Benjamin Joffe" <canvasgame at gmail.com>; "Andrew Fedoniouk" 
<news at terrainformatica.com>; "David Hyatt" <hyatt at apple.com>
Cc: <whatwg at whatwg.org>
Sent: Friday, October 20, 2006 11:40 PM
Subject: Re: [whatwg] Canvas draw quality


> On Sat, 21 Oct 2006, Benjamin Joffe wrote:
>>
>> I would like to see a property added to the 2d canvas context that would
>> allow quality to be lowered for drawing functions. Normally any time a
>> shape is drawn, pixels close to the boundary are made semi transparent
>> to make it look smooth, this is usually favourable but I have had a need
>> to draw shapes and lines with pixel sharp boundaries in the same way as
>> Java normally does.
>
> You can do this already using the getImageData() and putImageData()
> methods -- get the area that you want to affect, modify the device pixels
> you want to affect, and then redraw it.
>
>
>> This property could also be handy in instaces where both fill() and
>> stroke() are being called. Low quality could be used on the fill() to
>> improve performace while stroke() could be used with high quality so it
>> still draws smoothly.
>
> There's no reason UAs can't already do this optimisation. In fact, it
> would be better for UAs to do these optimisations than for authors to have
> to remember to do them.
>
>
> On Fri, 20 Oct 2006, Andrew Fedoniouk wrote:
>>
>> I think that the best way is just to define different values for the
>> context ID: DOMObject getContext(in DOMString contextID);Something like
>> "2D" and "2D-fast" or "2D-simple". Another option would be to add one
>> optional parameter to the getContext() function.
>
> I agree with David Hyatt's comments here.
>
>
>> I doubt that someone will need to switch it in the middle of drawing so
>> having such switch as an attribute is redundant.
>
> The two use cases that Benjamin gave were both cases where you'd switch in
> the middle, actually.
>
>
> On Fri, 20 Oct 2006, David Hyatt wrote:
>>
>> I don't think an API like this should be vague about what it's doing...
>> e.g., just using vague terms like "quality."  We should say what we
>> mean... antialiasing for example.
>
> I strongly agree with this. But I don't think we should realy go there,
> certainly not at this stage of the game.
>
>
> On Fri, 20 Oct 2006, Andrew Fedoniouk wrote:
>>
>> Dave, various implementations use different libraries/approaches for the
>> Graphics. Way of tuning parameters and their set can be different. I
>> think that it is simply not possible to generalize them all.
>
> That's a good reason not to add them at all.
>
>
>> At least something generic like preference=quality/speed switch makes
>> real sense.
>
> I would imagine that most people would rather implementations were both
> fast and had high quality all the time.
>
>
> On Fri, 20 Oct 2006, David Hyatt wrote:
>>
>> Except with something like canvas, people are going to care about the
>> precise pixel-level details of the rendering.  We can't handwave these
>> details away using vague terminology like low-quality or high-quality,
>> where the user agent is free to decide what those terms mean.  If we do
>> that, then we risk not having interoperability between browsers.
>
> Exactly true.
>
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>