Wednesday, January 7th, 2009

Watch out for the zoom; Debugging fun with Canvas

Category: Canvas, Debugging

Ben was cursing at a bug in some canvas code that he was playing with, where the rendering was off. One piece of his UI was blurred instead of crisp.

The debugging exersize was fun, and he shares it with you on his personal blog.

The moral of the story is: watch out for that zoom feature in today's browsers!

Along the way, I got to learn that canvas supports fractional coordinates:

My first thought was that it would be due to fractional coordinates. I have years of experience with drawing APIs that force integer coordinates, so I’m used to relying whacking off the fractional part of a coordinate and making up the difference when necessary in a second pass. Canvas, on the other hand, supports fractional coordinates, which I’m told is the fancy thing to do these days. (How the fraction is converted to an actual pixel is depenendent on whatever drawing system is doing the heavy lifting somewhere down the stack.) When your coordinates are fractional, you can get this kind of fuzziness.

Because the interface I’m working with involves a few layers of rendering code, ensuring that integers ruled the roost took some time. But after quite a bit of poking around, I found no evidence of fractional coordinates. It was around this time I saw Vlad (Mozilla’s graphics guru) walking around the office and asked for some help.

We started looking for evidence of transforms that would introduce fractional coordinates–but ultimately came up empty handed. As we went through this process, he pointed out that the <canvas> context instances are reused, so it’s a really good idea to save() and restore() when obtaining a canvas to avoid polluting the context:

javascript

  1. var ctx = canvas.getContext("2d");
  2. ctx.save();
  3. // painting here
  4. ctx.restore();

I had assumed each call produced a fresh, stateless context, so this was welcome news indeed.

But, user error was the true case:

And that’s when we noticed that I had zoomed in a click using Firefox 3’s fancy full page zoom feature. And that was causing the image the be scaled up, and the blurriness.

Posted by Dion Almaer at 8:49 am
7 Comments

++++-
4 rating from 11 votes

7 Comments »

Comments feed TrackBack URI

Too bad there weren’t scalable graphics you could use in a browser… ;)

Comment by codedread — January 7, 2009

codedread has a good point. Shouldn’t Scalable Vector Graphics be scalable?

Comment by tj111 — January 7, 2009

You missed the point, this was a Canvas experiment/problem. They’re not using SVG…

Comment by codedread — January 7, 2009

This is why we need 200 dpi screens. Once you can’t actually see individual pixels anymore with the naked eye, you don’t have issues with crispness or aliasing ever again. The hardware makers and the web stack are ready for that today, we’re just waiting for the desktop OS’s to catch up.

Comment by Joeri — January 7, 2009

My Firefox cannot render that canvas element after “that the”, you might check your syntax ;)

Comment by randomrandom — January 7, 2009

@tj111 and @codedread: ya, this is from a canvas project, using canvas for a reason. :-)

Comment by Ben Galbraith — January 7, 2009

Thanks. I’ve run into this myself with a major Canvas project I’ve been working on. Preciate the shared insight, Ben.

Comment by leachryanb — January 8, 2009

Leave a comment

You must be logged in to post a comment.