[HOpenGL] Pure, garbage-collected graphics resources

[minh thu]

2009/7/21 Conal Elliott <conal at conal.net>:
> Thanks for these comments
>
>>
>> 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 ?
>
> This "data-centric" style (I like that term) is exactly what I like to do in
> all of my libraries, and it's what I'm doing again now.  OpenGL types are
> hidden in the library implementation, and the exposed semantics is
> unaffected by the imperativeness of OpenGL (just as the semantics of Integer
> is unaffected by the imperativeness of 'print').
>
> And then I find myself in an implementation puzzle.  My 'run' function (for
> the purely functional type) involves creating VBOs and textures, which
> greatly accelerate rendering.  I want to *reuse* these resources without
> mutation (i.e. reuse the content, not the memory), which is easy if they're
> wrapped up as functional values that go into my higher-level functional
> values, but tricky if they get created only during 'run'.  Another example
> is shader programs, which I synthesize and then never mutate.
>
> Since I'm using this graphics data in a purely functional way, I want both
> creation and destruction to be handled in a functional way, i.e., lazy
> evaluation and garbage collection, with no visible IO.  I think we can
> finally get there, now that we have dependable prompt execution of C-based
> finalizers.
>
> However, I do not think robust finalization can be added on top of the Ptr
> type, which is used in HOpenGL, because GHC optimizations often drop
> constructors (like Ptr) keeping only the contents, which allows finalizers
> to get called much too soon.  Some examples of this general problem are
> mentioned in the addFinalizer documentation [1].  I think a solution would
> be to replace Ptr with ForeignPtr in HOpenGL.

I have no clue about the low-level working of finalizers, but...

All you explain here makes me think about the examples of the papers,
namely, memoizing functions.

The functional value you want to manipulate acts a bit like the nice
given-to-the-user-to-see memoized version of the original function.
That is, instead of wrapping the mechanics used to do the book-keeping
for the memoization, here we need to do the book-keeping of the actual
OpenGL ids (I assume it is possible to 'name' things in haskell in a
functional-friendly manner and those names are 'translated' by the run
function into GLuint and GLint returned by functions like
glGenBuffers).

But maybe all this boils down again to the problem you mention about Ptr.

Can you explain how you want things to work ? Say you have your
textures, shader programs and vbos created (with already the actual
OpenGL calls made or not, that is the values are either placeholders
or really the OpenGL data). Now you want to reorganize those with
possibly new shaders, textures or vbos. Can this reorganization be
explicitely in the IO monad or not (in your view)?

Cheers,
Thu