[Haskell-cafe] [C Binding] Turning the mutable to immutable?

[Yves Parès]

Okay,
so I think that the better idea is to carry on with my low-level, imperative
binding, and then build a more functional on top of this.

Concerning the mutability of images, I notice that the problem with SFML is
that it handles Sprites in a way that is even more imperative than OpenGL
texture handling.


2010/7/7 Sebastian Sylvan <sebastian.sylvan at gmail.com>

>
>
> On Wed, Jul 7, 2010 at 2:24 PM, Yves Parès <limestrael at gmail.com> wrote:
>
>> > 2010/7/7 Liam O'Connor <liamoc at cse.unsw.edu.au>
>>
>> > Making an immutable API from a mutable one generally damages performance
>> (on von neumann architectures) somewhat, the goal is to minimize that
>> impact.
>>
>> In fact, I would like to determine if an EFFICIENT way to make images and
>> such immutable exists, or if it is impossible.
>>
>
> Both OpenGL and DirectX, while supporting updates to images, make it slow
> enough that any image data is effectively immutable. Each animation step a
> completely fresh frame buffer is created, without overwriting any of the
> inputs, by combining these immutable images in interesting ways.
>
> You're expected to combine multiple immutable data sources in the shader to
> produce the final output (which will be a different image from the inputs).
> Examples of data sources would be images, transformation matrices, colours
> etc.
>
> It's extremely rare to see people poke values individually into a mutable
> buffer (in fact, the capability of doing this on the GPU is very recent, and
> even then it's highly limited). You do a big purely functional transform
> from inputs to outputs instead. HLSL and GLSL may not look like functional
> languages, but they essentially are, in that each kernel runs independently
> with no shared mutable state, producing outputs from immutable inputs.
>
> So, if you want to do it on the CPU, I would mimic the way GPUs have been
> doing it for ages. Define what operations you want to perform in terms of
> the inputs, and then do them all "in bulk" to produce the output image. You
> don't want people to go in and arbitrarily set pixels to anything they want
> at any time they want.
>
>
> --
> Sebastian Sylvan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100707/9927ba73/attachment.html