GUI library for D

Nick Sabalausky a at a.a
Wed Apr 6 13:41:57 PDT 2011


"Michel Fortin" <michel.fortin at michelf.com> wrote in message 
news:inhnnn$236n$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> I haven't benchmarked or even tested this, and heck, maybe I'm just
>>> a dinosaur, but for better speed and flexibility I'd recommend
>>> something more like what I've attached.
>>
>> Yea, that does sound better. Though I have a few comments...
>>
>>> The width is statically-known, so the compiler can optimize the
>>> index calculation from multiplication to shifts when appropriate.
>>
>> One concern I have here is will it be an incompatible type with
>> dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
>> cleaning up my png and bmp loaders in the near future to use with
>> this.)
>
> I don't think having fixed-size image will be a useful optimization, 
> except perhaps if you manipulate a lot of tiny images of the same size.
>

Manipulating images in software involves accessing a *lot* of pixels, so you 
have a very big "inner loop" situation. If the width isn't statically-known, 
then:

- Every arbitrary pixel access requires a multiply (instead of a shift or 
sum-of-shifts like you can do if the width is statically-known and a power 
of 2 or a sum of powers of 2).

- Every sequential non-horizontal pixel access requires an extra register to 
be used (to hold the pointer-increment value).

Over all the pixels in a scene, that can really add up. In fact, that's one 
of the reasons game engines traditionally have only supported very specific 
finite sets of fixed image sizes.

Of course, usually you'd avoid doing direct pixel access and use 
specially-optimized higher-level primitives instead (although even those can 
often benefit from a statically-known power-of-2 width). But since one of 
the goals behind this API is to be used as a "playground", we can expect 
that people are going to want to be doing a lot of direct pixel access.

Although, we'll certainly want to do some benchmarking to really know for 
sure.

>
> Don't forget that there's actually much more colorspaces than indexed and 
> RGB. There's RGBA (when you need semi-transparency), there's CYMB (for 
> print), there's grayscale. And in some cases HSV or XYZ could be useful 
> too. And for each of these someone might want different bit depth. Can't 
> we make things flexible enough for that by using a template?
>
> final class Bitmap(Color) : Image {
> void opIndexAssign(int x, int y, Color color) {
> pixels[y * width + x] = Color(color);
> }
>
> size_t width, height;
> Color[] pixels;
> }
>
> This way, you can have a bitmap of RGBColor, or RGBAColor (with an alpha 
> mask), GrayColor, IndexedColor, or whatever color type you can come with, 
> and algorithms can be reused.
>

Yea, that's probably a very good idea.





More information about the Digitalmars-d mailing list