On Friday, 10 July 2015 at 04:56:53 UTC, rikki cattermole wrote:
On Thursday, 9 July 2015 at 23:35:02 UTC, Vladimir Panteleev
wrote:
On Tuesday, 7 July 2015 at 03:39:00 UTC, Rikki Cattermole
wrote:
I've been sold on the unsigned vs signed type issue for and
only for the x and y coordinates.
The first version of ae.utils.graphics had unsigned
coordinates. As I found out, this was a mistake.
A rule of thumb I discovered is that any numbers you may want
to subtract, you should use signed types. Otherwise,
operations such as drawing an arc with its center point
off-canvas (with negative coordinates) becomes unreasonably
complicated.
Canvas API != image library.
I'm quite happy for the canvas API to use signed integers.
While the image library does not. After all the canvas API
would just wrap how its being stored.
Why must there be a distinction between canvas and image? Seems
like a pointless abstraction layer.
You lose the ability to have such large images as the CPU
architecture can support but meh. Not my problem.
No, that's wrong. The limit (for 32 bits) is 2 billion pixels for
signed coordinates ON ONE AXIS. So the only situation in which an
unsigned width/height will be advantageous is a 1-pixel-wide/tall
image with a 1-byte-per-pixel-or-less color type.
The canvas API being built on top should sanitise coordinates
as need be. This is not unreasonable.
I think it is. If you want to draw something 10 pixels away from
the right border, the expression img.width-10 will be unsigned.
