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