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. `._.-(,_..'--(,_..'`-.;.'
