Fast 2D Raster Rendering with GUI

[Ivan Illarionov]

On Mar 19, 2:33 am, dave <man... at gmail.com> wrote:
> First I want to say thank you all for your timely replies. This is all
> good food for thought. I've been programming more many years, but fast
> graphics rendering is new territory for me.
>
> I'm hoping to fine something like a buffer_blit, where I can set all
> the pixels to change using basic operators, blit them all at once to a
> pixel buffer, then swap the visible buffer. Ideally it will only
> change the region of the pixel buffer that needs changing.
>
> Because I want layers, I would like to take advantage wherever
> possible of the available hardware features. I.E. ideally I am hoping
> that the layers can be textures in memory that get composited in
> hardware onto the screen. Maybe this is wishful thinking though?
>
> I'm also thinking that maybe I can reduce the number of active layers
> from N down to 3 - the active layer, the layers below it, and the
> layers above it. Obviously only the active layer needs any sort of
> sprite-like animations and it on this layer than response time is most
> important. Having to layer the top layers ontop of it may also play a
> factor but, as I suggested, I can merge them all together in one time
> and then use the merged result to layer on top of the active layer.
>
> I'm a little nervous about going the C/C++ route. It's been a few
> years since I used them, I'm new to Python, and jumping into coding
> Python extensions with C/C++ is not particularly palatable (though
> I'll do it if I have to.)
>
> > Any GUI toolkit will work if you find the low-level access
> > to their image memory buffers.
>
> That's another new step for me. Any ideas where to start? Thanks!

Some reading on fast 2d graphics:
chapters 35-42 from
http://www.byte.com/abrash/

and a lot of great stuff here:
http://tog.acm.org/GraphicsGems/