Re: Pure, garbage-collected graphics resources

2009/7/21 Conal Elliott <[email protected]>:
> I'd like to use some OpenGL resources (VBOs, textures, shaders, and shader
> programs) in a functional way, with immutability, garbage collection, and
> IO-free creation interfaces.  Has anyone played with doing such a thing?  I
> guess the GC part would involve foreign pointers with foreign finalizers
> (which now run promptly in GHC iiuc).  I don't know of any reliable way to
> add finalizers to Ptr values, because of the unboxing problem [1].
>
> One tricky issue is that graphics context initialization must take place
> before any of these "pure" resources get evaluated.  If the APIs allowed
> access to to multiple graphics contexts, things would get stickier.
>
> Comments?

Hi,

I wanted to point you to a paper (Stretching the storage manager: weak
pointers and stable names in Haskell) but see you're one of the
authors.

As you say, there is the notion of context. I guess you can create the
context with something explicitely in IO, like

createContext :: IO Context

then implementing the "pure" resources as data structure referencing
the context.

Anyway, I've not a clear picture of what you have in mind (especially,
at which point in time a, say, VBO should be considered to be part of
things to be rendered). Often, a data structure (say Blah) is created
in a pure way then given to some kind of run :: Blah -> IO () function
for "interpretation". Why not mirror the OpenGL API in a purely
data-centric way then give the data to the run function ?

Although the OpenGL C API is imperative, it maps fairly well to a
data-centric approach.