GUI library for D

[Dmitry Olshansky]

On 07.04.2011 0:11, Nick Sabalausky wrote:
> "Adam D. Ruppe"<destructionator at gmail.com>  wrote in message
> news:ini1jr$2lj3$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> Of course, if you see any fundamental
>>> problems with this, feel free to let me know :)
>> I'm pretty sure your plan would work and would provide a boost,
>> but I'm not sure if it's worth the extra time.
>>
>> I think the best thing to do will be to partially implement it,
>> write a little program with both methods and run some speed tests.
>> See if it's still easy to use and how big the difference really is.
>>
>
> Yea, sounds like a good plan. Although, my design is heavily dependent on
> inlining working, so that may be a problem until DMD issue #5708 gets fixed:
> http://d.puremagic.com/issues/show_bug.cgi?id=5708
>
> There another similar -inline related bug in there too, but I don't remember
> offhand what it is.
>
>>> And even then, things like line drawing, fills and image
>>> blitting are still better off skipping the
>>> individual-pixel-access routines
>> Aye, even my homegrown DOS would always write them separately.
>> Horrible waste of instructions doing another y<<  8 + y<<  6 when
>> a simple "inc ax" would suffice!
>>
> Yup, exactly. Which reminds me, I've always wanted to actually check to see
> if modern compilers (or at least DMD) would be smart enough to optimize
> something like:
>
> for(i in 128...256)
>      arr[i] = ...;
>
> Into something like:
>
> auto ptr = arr.ptr + 128;
> auto ptrEnd = arr.ptr + 256;
> for(; ptr<  ptrEnd; ptr++)
>      *ptr = ...;
>
> My guess is no (and I'm fairly certain it was "no" back in my DOS days: that
> was the sort of manual optimization I remember doing all the time), but with
> all the improvements that optimizers keep making, I'm not really sure
> anymore.
>
> Of course, even if the compiler can optimize that, I still doubt it would be
> able to automatically do an equivalent optimization to effectively create,
> for example, Bresenham's algorithm (ie, straight diagonal lines between two
> arbitrary points).
>
>>> But anyway, I don't know exactly how you were going about it, but
>>> the way to do this in OpenGL or DirectX would be to do all your
>>> drawing to a texture buffer
>> I at first just used a SetPixel function in opengl, but when it
>> was unacceptable, I simply abandoned the idea of drawing pixels
>> to the screen. Instead, I started focusing on polygons and textures -
>> a rectangle with a bitmap attached as a texture makes an excellent
>> sprite that draws very very quickly, even if rotated or misshapen.
>>
>> Once I realized that works so well, pixels weren't important
>> anymore so I just stopped using the old functions entirely. They're
>> still in the code, still godawfully slow, but I don't care enough
>> to change it.
>>
> Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we
> could do better (as long as we had direct access to the texture's buffer).
>

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

-- 
Dmitry Olshansky