Re: [boost] GIL Graphics Examples

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-10-17 15:44:40

On 10/17/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> wrote:
> I'm using a library called DirectFB, which is a relatively thin wrapper
> around 2D hardware graphics acceleration.  Operations like rectangular
> copies and fills are hugely faster than letting the CPU do the work.

Isn't this only possible on hardware with Frame Buffer Object support,
or does DirectX not have the same limitations as OpenGL?  In OpenGL,
if the OpenGL context is not visible, the contents of the frame buffer
are undefined, so one has to use Frame Buffer Objects or PBuffers to
do what you are talking about.

Definitely not a show stopper (we do similar things for calculating
Line of Sight where I work), but something to keep in mind.

This is traveling down the route of needing an accelerated graphics
library in Boost...think of all that your request entails.  Querying
graphics hardware for capabilities, setting up extensions (if OpenGL),
FBO construction, rendering to target, etc.   Your request requires
nearly a full graphics pipeline if you want to do it correctly and
extensibly.

> x86 hardware also has the MMX and SSE SIMD instruction set extensions
> which can give significant speedups, e.g. processing the 3 8-bit
> channels of an RGB pixel (or potentially 2 or 4 pixels) in one instruction.

This seems like a good extension to GIL.

> So I have been wondering about how a graphics library that's not
> hardware-specific, like GIL or Anti-Grain or FreeType, can best be
> combined with hardware-specific features.  For example, if I want to
> draw a rectangle with curved corners, then ideally I'd use the graphics
> hardware to draw the body of the rectangle and then do the details of
> the corners from the CPU, using MMX instructions to process whole
> pixels at a time.  What sort of architecture would allow the maximum
> exploitation of available speedups, with the simplest possible interface?

At the top level the interface wouldn't change too much, but the
amount of code inside the library would be pretty large (for reasons
given above).  The last thing to mention is that creating and
destroying the rendering context will probably be one of the huge
bottlenecks.  For instance, if you had 100 rectangles that you wanted
to do this to, you wouldn't want the underlying call to
create_curved_corners to create an OpenGL context every time, then
destroy it on function exit.

I'm not sure how to get around that without exposing implementation
details to the user.

--Michael Fawcett