- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 13 Jun 2009 22:33:32 -0400
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 <http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/>). 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
Received on Saturday, 13 June 2009 19:33:32 UTC