Initial feedback for std.experimental.image

[Vladimir Panteleev via Digitalmars-d]

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.