On Apr 26, 2014, at 3:53 PM, Niklas Hambüchen 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-BufferO....

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. Anthony

...

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.

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Apr 26, 2014, at 10:28 PM, Michael Baker 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 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-BufferO....

...

On Sat, Apr 26, 2014 at 3:13 PM, Anthony Cowley 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

Thanks! On Sun, Apr 27, 2014 at 8:15 AM, Niklas Hambüchen wrote:

Yes, what Anthony says. I create the BufferObject from the Vector when what I want to render changes (which happens less frequently than every frame), and each frame then renders from the BufferObject.

If you want to change single elements, like he says, the mutable vector should make you happy.

On 27/04/14 04:54, Anthony Cowley wrote:

...

...

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