GUI library for D

[Nick Sabalausky]

"Dmitry Olshansky" <dmitry.olsh at gmail.com> wrote in message 
news:inik5u$n13$1 at digitalmars.com...
>
> Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL 
> ?  It's must have been GDI.
> At any rate OpenGL and DirectX is all about sending commands and data back 
> and forth between  CPU and videocard (well, there is driver involved, 
> doing some translation into specific chip's commands and such).
> So no, SetPixel couldn't exactly get inlined just because you can't access 
> video ram without jumping through some hoops:  OS -> HAL-> 
> driver ------->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX 
> subsytems bypass some of these additional hoops, but still you have to 
> send the data down this route. That's why it's usually used for massive 
> asynchronous transfers.
> E.g. every time you need GetPixel you send "read pixels command" and wait 
> utill all the data already streamed in is processed and stored in the 
> video RAM, then it reads framebuffer and sends you results (effectively 
> stalling all it's processors).
> So for "straight" setpixel/putpixel drawing, software render + blit to 
> screen is the way
> (but I  doubt you need only pixels, and going futher inevitably shows why 
> software render sucks).
>

What I was thinking of was using some set/get pixel stuff to draw to 
system-ram and then use OpenGL/DirectX to transfer it to video-ram when done 
(I have no idea which way Adam was doing it).

And yea, you're right that software rendering sucks performance-wise. But 
the main orginal point was t have a way to just toy around with image 
drawing in an easy classic DOS-style. From there, my thoughts were "ok, how 
to make this approach as close to being efficient as it can realistically 
get?"