Hi.

I have a problem regarding html 5 canvas in a browser. I draw a rectangle on canvas with rect then fill method. I realized that this rectangle then becomes immediately subject to antialising. The problem is, that I create many rectangels perfectly next to eachother thus I get seams due to antialias technique. What worries me even more is totaly stalked performance, as I draw many rectangles, not only those seams. It suprises me that there is no way to issue to canvas to not antialias current draw operation. Is it realy so? Since performance is vital to me , a solution of invalidating antialising result by some trick is too unacceptable in my situation. Antialiasing is anyway a technique to smooth edges, and canvas thinks that edge of every draw operation is to be an edge in end result. I do not get it. Please, give me some hints on what draw operations on canvas are not subjected to antialias, or how to issue to not antialias a current call. Some direct "put pixel in" would not be antialiased I hope, if couting on designers having had at least some sanity :(

Did you search the web? I found relevant links like this one in like 10 seconds...

Since performance is vital to me , a solution of invalidating antialising result by some trick is too unacceptable in my situation

And that is all that web contains. Smoothing out horizontal/vertical lines, in a way that theiy are placed always at a middle of a pixel (x+0.5) to cover up a pixel exactly so antialiasing does not take a stand. This of course is not doable with other directions.

That was just an example of what I found. But it looks like you'll have to write your own drawing primitives to get what you want. The results might be too slow, of course...

Could you post an example of that?

I never had such problems, maybe your canvas has some weird css scaling that causes the browser to interpolate the contents.

WAW! Please elaborate on this further! Here is a simple follow-up to reproduce the problem.

-Have a canvas of arbitrary dimension

-call context.rect(0,0,50,50);

-call context.fill(); // you may have any pattern set on context, color or image...

-call context rect(50,0,100,50)

-call context fill();

With this you will have two rectangles next to each other with a white seam between them.

Of course, this might be made not accounting the aa effect by drawing them translated by 0.5. But consider other shapes that do not have vertical orthogonal definition and neighbourhoods in floating space, like paths for example that get filled. Example:

have a canvas of dimension 800x800

-call context.beginPath()

- call context.moveTo(0,0)

- call context.lineTo(100,50)

- call context lineTo(0,50);

-call context.closePath();

-call context.fill();

-call context.beginPath()

- call context.moveTo(0,0)

- call context.lineTo(100,0)

- call context lineTo(100,50);

-call context.closePath();

-call context fill();

you will gain a diagonal seam in a red square.

Frankly I worry about performance more than the AA effect - but for this I should know a fundamental knowledge- "Is magnifying filtering as expensive as AA, thus AA is just magnifyning filtering?", it is a fact that textures are always magnified, for in case that they do not have to be, a lower mipmap level is sampled- as a believe that used is always the mipmap of the level that a real target pixel covers less than texture pixel. I have never seen a sharp texture in my experience unless I disable min/mag filtering- but then you get squares at magnification case. If someone would clarify this... wheather AA is just mag filter applied on border pixels that samples already drawn target pixels at those borders, as I realized that if background is white I get a white seam, if green I get a green seam. Also, I do not know wheather canvas uses mipmaps, or not, or I will have to create patterns for them manualy.

I have pasted the disable code to the fiddle, it did not remove seam though. I need to know wheather AA is the result of mag filter, or of another alogorithm. In case it is the mag filter, then I am ok with the performance cost totaly and I will not seek disabling AA, for I can invalidate seam result cheaply. If someone could tell this specific information I would be so glad. Thanks for now anyway.

If you want to now it more precise go and checkout the webkit sourcecode and see the implementation going on there.

nope

As said the image smoothing only affects images, not any primitive drawing operations.

This does not clear wheather AA is algorithm out of smoothing images, or separete proccess. There are three drawing calls :

stroke() and fill() and drawImage() , and they all can apply pattern, in case the pattern source is an image, filter applies, if not, aa is preserved still, making me gess it is just optimalized smooth filter. All I would need to know is wheather AA is result of actual image smoothing, or not