GUI library for D

Michel Fortin michel.fortin at michelf.com
Wed Apr 6 05:49:36 PDT 2011


On 2011-04-05 23:07:33 -0400, Adam D. Ruppe <destructionator at gmail.com> said:

> Note: I just updated my simpledisplay.d. My color constructor
> said b = c when I meant this.b = c... hence everything was yellow!
> You can download again from the same place.

I played with it yesterday and never found why the blue channel didn't work!

By the way it works well with X11 on Mac OS X (if I change the "version 
(linux)" to "version (OSX)").

I also made a working OS X implementation (Cocoa).


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


> Maybe it could use an interface to smooth that over.
> 
> I actually had a similar fight with myself over Indexed vs TrueColor
> when writing the original thing. They really don't have compatible
> interfaces. Sure, you could do some kind of putpixel(uint data)
> for each of them, but it's not really the same.
> 
> So I think they should be separate types, with functions to convert
> back and forth. (both conversions being lossy in their own way..
> just because two palette entries have the same rgb values doesn't
> mean the two colors are semantically the same.)

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.


> Wow, I'm off topic again. Anyway, for the event loop here, I'm
> thinking something similar to how std.concurrency does it might
> be a good approach: a bunch of delegates, matched to events by
> their signature. Simple signatures could be accepted as well
> as fancier ones.
> 
> // need to make a simple window separately here so it is persistent
> auto win = new DrawableWindow(width, height);
> 
> // still use an image the same way. Alternatively, DrawableWindow
> // could implement the same interface as Image, probably double
> // buffering internally anyway, so pretty much same implementation.
> auto image = new Image(width, height);
> 
> window.eventLoop(
>    50, // first parameter is the timeout. can be 0 to only react
>        // to events, but putting one in gives you an easy to use
>        // frame pulse for drawing
>    (int keyPressed) { // might be a struct KeyEvent rather than int
>         // react to the key
>    },
>    (int x, int y, int mouseButton) {
>         // react to a mouse click
>    },
>    () { // no params means your timeout happened, time to draw
>         // draw your frame...
> 
>         image.display(win); // this overload uses the existing
>                             // window and returns immediately
>                             // rather than making and waiting
>    }
>    // might also offer a platform specific msg, wParam, lParam
>    // so you could in theory do all of Win32 based on this same
>    // framework
> );

Overall, I really like this concept. I'd like it better if 
image.display(win) was replaced with "window.image = image" however.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list