Simplification pass on GPipe-GLFW

[plredmond]

I'd like to do a pass on GPipe-GLFW to simplify things. The current implementation is much too complex. When I wrote it I thought we were going to facilitate having multiple threads, but then that feature was removed from GPipe. The corresponding complexity in GPipe-GLFW was never removed.

If you think we should keep the simplifying assumption of being single threaded, I'll go ahead and make that change over there.

[tobbebex]

Yep, you might as well! :)

If I ever find time to it, I would like to make a GPipe 3, based on Vulkan, and without the pesky os parameter everywhere (implicitly allowing sharing everywhere within a process, with Haskelly threadsafety based on immutability and monads)

[plredmond]

Great! I have some questions about corresponding simplifying assumptions:

• Can I assume that all ContextHandler functions are only ever called on the main thread? (contextHandlerCreate, contextHandlerDelete, createContext, deleteContext contextDoAsync, contextSwap, and contextFrameBufferSize)
  • Since we don't support threading, and the initialization can only occur on the main operating-system bound-thread, it seems to follow that all of these methods can only be called on the main thread. Is this right?
• Depending on your answer to the above: Can I assume that there is only ever one context? (Ie. createContext returns the same context created by contextHandlerCreate and deleteContext is a noop.)
  • If we assume that everything occurs on one thread, do additional contexts have any utility? (Beyond, perhaps, facilitating the opening of multiple windows?) I'm unsure.

Depending on the simplifying assumptions, I might try to implement a GPipe-SDL and then with that completed turn back and streamline GPipe-GLFW. I'm not sure.

---

GPipe3 for Vulkan sounds cool! I don't really know how to go about upgrading my knowledge from OpenGL to Vulkan though.

There's also a question of who GPipe is for. It sits at an odd place: Graphics programming experts might find it too high level, and novices might find it too low level. It's perfect for me, somebody who wants to play with amateur graphics and lighting models without getting bogged down by OpenGL API pitfalls, but I don't know whether I represent the majority of Haskellers looking to make 3d graphics or not.

[tobbebex]

ContextHandler is only ever called from the same thread right now, yes, but there might be multiple contexts. I dont see the use case for it, which is why I think I should have made it a single context implicitly and skipped that os type argument in the first place. But as it is right now, multiple contexts are supported...

I guess GPipe was for myself back when I made it :) It was fun to explore how typesafe I could make the core OpenGl specification in a type system as expressive as Haskells.

[plredmond]

Ok!

1. Same thread 👍
2. Multiple contexts 👍

Asking just for curiosity, for #2, if createContext just returned the same "singleton" context made by contextHandlerCreate, would anything break? Would it be observable? (Having multiple windows would break.. Would anything else?)

I hope you do make another GPipe in the future, fwiw.

On Dec 13, 2020, at 13:54, tobbebex notifications@github.com wrote:

ContextHandler is only ever called from the same thread right now, yes, but there might be multiple contexts. I dont see the use case for it, which is why I think I should have made it a single context implicitly and skipped that os type argument in the first place. But as it is right now, multiple contexts are supported...

I guess GPipe was for myself back when I made it :) It was fun to explore how typesafe I could make the core OpenGl specification in a type system as expressive as Haskells.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[plredmond]

Closing this because we agreed on the changes to make