On Apr 26, 2014, at 10:28 PM, Michael Baker <michaeltbaker@gmail.com> wrote:

> On 26/04/14 19:24, Michael Baker wrote:
> I've thought of several things to try including:
>  * Only allocate an array when the number of circles changes.
>  * Convert a circles into a C struct and "poke" them directly into an
> existing array instead of going through the intermediate form of a list.
>  * Do some manual memory management and index each circle into a
> preallocated array, only updating the values of the array that
> correspond to circles which have changed.

> On Apr 26, 2014, at 3:53 PM, Niklas Hambüchen <mail@nh2.me> wrote:
>
> Using a Storable vector is what I mostly do.
>
> It goes nicely with rendering arrays of objects using OpenGL
> `BufferObject`s, using `fromVector` from
> http://hackage.haskell.org/package/GLUtil-0.6.4/docs/Graphics-GLUtil-BufferObjects.html#v:fromVector.

> On Sat, Apr 26, 2014 at 3:13 PM, Anthony Cowley <acowley@seas.upenn.edu> wrote:
> I second this recommendation. If you are doing frequent updates on a small subset of these values, I have most of an interface for doing so, but I haven't bundled it into GLUtil yet, so let me know (better: open an issue on github) if the existing interface just doesn't work for you.

So do you all just create a new vector every frame? Could you go into a little more detail?

You can create a new vector every frame, or you can use a mutable vector that you freeze before passing to 'fromVector' or 'replaceVector'. You can also investigate using, say, 10 vectors of 1k elements each if your updates are spatially correlated somehow.  I do the latter when I am generating new data over time, for example. The nice thing about using Vector is that you can use it like an array that you peek from and poke to, or you can take advantage of the fusion machinery to generate or update it on the Haskell side before shipping the underlying data off to OpenGL.

The specifics of your update patterns will govern what is the best strategy.

Anthony