[plt-scheme] graphics states and Scheme

From: Dave Griffiths (dave at pawfal.org)
Date: Wed Jul 4 11:03:17 EDT 2007

> On Jul  4, Dave Griffiths wrote:
>> [...]
>> So this seems to work well, and is very standard stuff for scene
>> description. The main point is that it reduces the overhead of
>> specifying and sending data, as (I think) the full functional
>> approach would be to specify the entire state as arguments each time
>> you build a new primitive.  For animation you would also need to
>> specify the entire scene each frame for animation rather than using
>> a scenegraph (fluxus has an immediate mode for doing this, and it is
>> useful - but it's much slower for obvious reasons)
> I'm not sure I understand the problem well, it looks like you want a
> combination of a functional description and the efficiency of not
> `draw'ing a cube on each frame but using some GL ability to name an
> object and move that -- can you say more?

Well - I'm not sure there is a problem really, I'm just interested in
alternative approaches for graphics programming.

There are two separate areas really - the need for retaining state inside
the engine (and then querying or modifying it) is a performance issue, and
I'm not too concerned about that.

The main thing is the scene description langauge, which currently involves
an implicit state stack, and lots of small simple functions. I found this
some time ago: http://www.dcs.gla.ac.uk/~meurig/research/early/ which
points in some interesting directions.



Posted on the users mailing list.