Initial feedback for std.experimental.image

rikki cattermole via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 9 22:27:18 PDT 2015


On Friday, 10 July 2015 at 05:01:57 UTC, Vladimir Panteleev wrote:
> 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.

A canvas API may only be in name only.
In other words, instead of it taking size_t it would take 
ptrdiff_t in e.g. free-functions.

>> 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.

Okay okay, I'm getting picky I know its silly.

>> 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.

Okay you have a point here with img.width.

Humm, complicated problem here. To the average developer having 
to wrap up an image type with e.g. CanvasImage before using it, 
even if it was a struct would just seem useless. Just to change 
index types to be signed.

What we need is a unsigned integer type of word size that can 
have an out of bounds value aka negative. While also supporting 
calculations that is both signed and unsigned.
So basically a unsigned integer behaving like a signed one.
Now wouldn't that solve the problem we have?


More information about the Digitalmars-d mailing list