Boris Zbarsky bzbarsky at MIT.EDU
Sat Jun 13 19:33:32 PDT 2009

```Boris Zbarsky wrote:
>> It's not that hard, it's an extra four or five lines of code to fill
>> in multiple pixels in a square (two nested for-loops and an expression
>> or two to work out what the limit is). Compared to the maths such code
>> would be doing anyway, this is trivial stuff.
>
> The hard part is realizing you have to do it...

And in particular, the fact that it's not just filling in multiple
pixels in a square...

For another example, consider an algorithm that wants to reduce the size
of the image by 1px horizontally (e.g. content-aware image resizing as
demoed using canvas at
If we're shrinking by one device pixel, then suddenly we can't even
create a canvas of the right size for the new image, because canvas size
is specified in integer CSS pixels.  Note that the algorithm used here,
basically off-the-shelf, would in fact want to work on device pixels the
way the spec is written right now; in general it would want to work on
whatever pixels imagedata is in.

If we want to shrink by one CSS pixel, so we can actually draw the
canvas, then each shrink step needs to apply the algorithm N times,
right?  But what if N is, say, 2.5, as it can be in Safari?  It's been
pointed out before that 1 css pixel can map to a fractional number of
device pixels there...  That algorithm can't very well be applied 2.5
times.  Of course my Julia set example would also need to do something a
lot more interesting than just "fill in multiple pixels in a square"
when the css-to-device pixel ratio is non-integral.

Note that I don't have a proposed solution here; I'm just pointing out
that the authoring pitfalls here are a lot more complicated than you
seem to give them credit for.

-Boris

```