Planning changes to GPipe-GLFW

[plredmond]

@sorki @SwiftsNamesake @grtlr @Kludgy @LinuxUser404 @MaciekFlis @bch29

Hello! I'm thinking of making some breaking changes to GPipe-GLFW to simplify the codebase.

• If you don't care about this, please let me know below and I'll remove your name from this issue so you don't get any more notifications. Sorry!
• If you do care about this, please read below and let me know whether these changes would cause you trouble in your projects.

---

GPipe-GLFW code is too complex because it was originally supposed to support multithreaded use. Since that was removed from GPipe, the corresponding code in GPipe-GLFW could be simplified too. I'm thinking of making some potentially breaking changes as a result.

• Do you, in any way, call GPipe or GPipe-GLFW functions from another thread? (If so, how? This isn't supported in ContextT currently)
  • If I remove the automatic RPCing of GLFW calls to a "correct" thread it could break multithreaded code, if any exists.
• Do you use the "mulitple contexts" or the "multiple windows" feature of GPipe?
  • If I remove this feature from GPipe-GLFW it would dramatically simplify things, but it would no longer be a correct implementation for GPipe. I'm curious whether anybody uses it.
  • Multiple contexts is kind of pointless since ContextT provides no way to fork a thread, but multiple windows might be a thing that people use.
• Do you use the "mainloop" or "mainstep" functions in GPipe-GLFW?
  • I'm considering simplifying or removing these.
• Would it break your code if GLFW callbacks were changed from IO to ContextT?

---

See also tobbebex/GPipe-Core#77

[sorki]

Proposed changes sounds good to me.

I've added another thread to my app recently for piping data over STM channels and it started to cause segfaults when app is running from ghci which this might fix (thread doesn't call any GLFW calls, they are all done in main thread).

I don't used any of the features you mention, changing callbacks to ContextT would just mean using liftIO . atomically for me.

[MaciekFlis]

My project that uses GPipe-GLFW is still quite small. The breaking changes you propose will be very easy to fix on my side. I would say go ahead.

[grtlr]

Thanks for letting us know! My project is also small, so no worries.

[Chatanga]

As an aside, since you are doing some cleaning on this project: is there a specific reason why the hints to change the OpenGL Core Profile are flagged as unconditionnal? I know the package is meant for GPipe which simply requires OpenGL 3.3, but I'm currently experimenting with a modified version requiring OpenGL 4.5 and it would be nice to use GPipe-GLFW without changes.

[plredmond]

Tobias told me to pass those hints because that's what GPipe uses! So that's an example of some poorly-thought out coupling between our libraries, I suppose. If you'd like to submit a PR to loosen that coupling and make it easier to work on your project, I'll try to get it merged. :)

…

On Wed, Apr 14, 2021 at 10:20 AM Florent Lioult ***@***.***> wrote: As an aside, since you are doing some cleaning on this project: is there a specific reason why the hints to change the OpenGL Core Profile are flagged as unconditionnal? I know the package is meant for GPipe which simply requires OpenGL 3.3, but I'm currently experimenting with a modified version requiring OpenGL 4.5 and it would be nice to use GPipe-GLFW without changes. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMG7YRZ4ZCWUNWCNFRYVNILTIXFGTANCNFSM4UY4J3RQ> .

[Chatanga]

In case you didn't notice, I’ve submitted a PR.