W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2007

[whatwg] Canvas draw quality

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 11 May 2007 18:28:33 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0705111823160.17396@dhalsim.dreamhost.com>
On Sat, 21 Oct 2006, Alfonso Baqueiro wrote:
>
> I wrote this little page to try the canvas
> 
> http://guia.sytes.net/notas/javascript/biorritmos.html
> 
> Is interesting that the drawed vertical 1px width black lines appear as 
> 2px width gray lines (in firefox) I suposse that is a colateral effect 
> caused by the antialiasing, so this simple case makes evident that we 
> need a method turn on/off the antialiasing.
> 
> I suggest:
> 
> var canvas = document.getElementById('canvas');
> var gc = canvas.getContext('2d');
> // some drawing
> gc.setAntialiasing(false);
> // some drawing
> gc.setAntialiasing(true);

Unfortunately, while authors like yourself are competent and can use these 
features correctly, a great number of people cannot. Such features end up, 
on many pages, being used incorrectly, sub-optimally, and in some cases 
cripplingly -- causing browsers that support these features to render 
certain sites significantly worse or slower (or both) than browsers who 
ignore these flags and instead apply heuristics to determine the optimal 
rendering modes.

Because of this, we can't really put these features in the spec -- they 
would just end up being abused, then ignored.


On Sat, 21 Oct 2006, Michel Fortin wrote:
> 
> Or maybe it just means you need to add half a pixel to your coordinates 
> instead of drawing directly between two pixels. Although rounding 
> everything to the nearest virtual pixel like this is not very good for 
> resolution independence.

Indeed, a further argument is that there are existing workarounds.


On Sat, 21 Oct 2006, Andrew Fedoniouk wrote:
>
> If display resolution will reach, say, 150dpi then antialiasing will not 
> be needed anymore. An there are such devices already.

Indeed, a further argument is that future displays will make this 
irrelevant anyway.


On Sat, 21 Oct 2006, Andrew Fedoniouk wrote:
> > >
> > > 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.

Indeed. But my point was that most authors would be unable to make a 
correct determination of the appropriate choice, and would pick randomly, 
with the results described above.


On Sat, 21 Oct 2006, Eugene Lazutkin wrote:
> > 
> > I doubt that someone will need to switch it in the middle of drawing 
> > so having such switch as an attribute is redundant.
> 
> It may make sense to do so for performance reasons. E.g., if someone 
> wants to draw a polygon with a border, it makes sense to fill the 
> polygon without any antialiasing of edges (for speed), and stroke a 
> border on top of it using antialiasing (for beauty). It is a pretty 
> common way to do complex drawings, e.g., maps. I assume that canvas 
> users will care about efficiency like everybody else.

While this is a valid use case, it is one that the browsers can themselves 
optimise -- e.g. by not performing the requested paints synchronously, but 
instead buffering them and determining which need anti-aliasing and which 
do not. Thus we do not need to provide controls for this level of detail.


Thanks for the feedback,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 11 May 2007 11:28:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:55 UTC