noeda / caramia Goto Github PK

Let user to wrap their own GLuint/whatever in most managed OpenGL resources and also to let them get it out. I'd prefer if this can be done in a consistent way across all the types.

I'm going to leave this issue here to track a problem with a way caramia (and OpenGLRaw) handle multiple OpenGL contexts.

The way things work now that all OpenGL functions are stored in top-level IORefs and when a function is called, it is fetched from IORef and called.

This works most of the time and with most drivers but some drivers report different function pointers when a new OpenGL context is set up (I've been told some drivers on Windows do this). So this is relevant for having multiple contexts active at the same time and also programs that may set up one context, tear it down, set up another one etc. in the same process (one application type that may do this is automated testing programs).

The second type of application (that doesn't use multiple contexts at the same time) can be dealt with by forcing the load of new function pointers whenever flextInit is called. The FlextGL module does this but the way of calling the function has a peculiar usage of unsafePerformIO in a normal IO action that might not actually end up using the reloaded function pointer.

Right now I don't think this is a serious problem because most applications just want one context in their lifetime as a process. I think safe multi-context might be difficult to implement without thread-local storage unless we want to abandon purely IO interface (I don't).

What do you think of abstracting most of the library over MonadIO? This would make life easier for people using monad transformers (like me), but it can introduce overhead (it can be mitigated for plain IO users with SPECIALIZE, though, to have no regressions). Exceptions shouldn't be an issue internally because you don't use transformers in the library (no MonadBaseControl stuff). I can try to make necessary changes if there is an interest, but I'd like to hear opinions first.
Another thing of interest may be to convert Draw into a monad transformer.

Ditto. I believe this is caused by usage of memset, but I don't have time to look into this right now.

This came as a request to my e-mail. I've been wanting to do this but haven't had an excuse to do so yet.

This work will involve going around the code, looking for features that depend on core 3.3 features and use an extension instead of the core feature. The ones that I can remember off the top of my head are framebuffers, query objects, sync objects, and some texture types. It should not be an insurmountable task.

Doing this should also be useful to explore OpenGL ES 2.0 backend as well (which is likely to have even less features, however it 2.0 ES does have framebuffers).

In terms of API friendliness, it would mean the user of the library may have to query before they use some feature to check if it is available. This would be no different from using plain OpenGL 2.1 and using extension queries to check what you can use. However, we could still say "If OpenGL 3.3 is supported, then all features in this library definitely will work".

Should not duplicate efforts, no, yes? gl didn't exist when Caramia was started. It would give us the raw bindings and as far as API goes you can use it in a very similar way to the FlextGL way.
https://github.com/ekmett/gl

I'll do this at some point.

What do you think of hiding map, map2 and unmap from Graphics.Caramia? One would access them if needed from Graphics.Caramia.Buffer, but generally withMapping{2,} are much more useful, and don't have names clashing with Prelude.

For example, newBuffer, newTexture, runDraws and draw all take a record value that have many fields, some are set, some or not. Now that we depend on lens, we could do something like this:

-- Old API:
-- newBuffer :: MonadIO m => BufferCreation -> m Buffer
newBuffer defaultBufferCreation { bufferSize = 123, initialData = Just some_ptr }

-- New API:
-- newBuffer2 :: MonadIO m => (BufferCreation -> BufferCreation) -> m Buffer
newBuffer2 $ (bufferSizeL .~ 123) . (initialDataL .~ Just some_ptr)

Some of the new convenience functions I wrote for Graphics.Caramia.Buffer already use this. The default value is supplied by the function itself; user changes fields they want. And lens is excellent at this kind of use.

TODO: Add lenses for all the specification records and export them. Add new API functions.