t.r.willingham: > As my first Haskell exposure, I've been working through Real World > Haskell. > > I am considering converting some of my C++ graphics libraries to > Haskell. I've done a fair amount of googling on the subject, however > I haven't quite been able to find clear answers to some of following > issues. > > (1) Using an OpenGL vertex array (a contiguous chunk of memory which > is handed to the graphics card) is important. I see the source code > of Frag does this, so it looks like we're good. Check. > > (2) In-place modification of the vertex array is important. Every > vertex changes on each frame update. And we always want more > vertices.
I imagine these are mutable arrays, so that's fine. > (3) Growing and shrinking the vertex array efficiently is important. > Here the behavior of C++ std::vector happens to be ideal. When > growing, extend the array in-place if possible (using reserved space > if any), otherwise allocate a new chunk ("amortized constant time"). > When shrinking, do nothing but record the smaller size; the unused > memory chunk is reserved for possible future growth. Easy enough. You're working with raw arrays of memory , I assume (e.g. UArrays or Ptr a?) > (4) Doing little to no allocations each frame update is important. In > the current C++ version, zero allocations occur during a normal frame > update. When the vertex array changes, that is the only allocation > which happens. This is certainly possible. To confirm it, look at the generated Core code, produced by GHC (with the ghc-core tool). See the realworldhaskell chapter on optimisation. > To give a context for all of this, I am applying a non-linear > transformation to an object on every frame. (Note: non-linear, so a > matrix transform will not suffice.) > > The object is described by a certain function, and is generated from a > 3D domain grid. The user can change the resolution of the grid on the > fly, while the object is moving. (Hence the need for grow/shrink > efficiency.) > > Given that (1) is out of the way, what's the best I expect from > Haskell concerning (2)-(4)? Seems fine. You'll be working at a low level, with strict, mutable, unboxed data structures, but that's fine: the machine loves them. -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe