search

z0w0 / helm

A functionally reactive game engine, with headgear to protect you from the headache of game development provided.
http://helm-engine.org/
MIT License
599 stars 69 forks source link

Move to NanoVG for SDL's 2D graphics #113

Open z0w0 opened 7 years ago

z0w0 commented 7 years ago

Use the NanoVG haskell bindings to get rid of the Cairo/Pango/Glib dependencies and move towards easier cross platform support

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/46210856-move-to-nanovg-for-sdl-s-2d-graphics?utm_campaign=plugin&utm_content=tracker%2F290443&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F290443&utm_medium=issues&utm_source=github).
nikita-leonov commented 7 years ago

It seems that Cairo etc for Haskell is actively supported with a last commit 6 days ago, meanwhile NanoVG last commit is 9 month ago. Do we really want to move to it, or there are more reliable options?

z0w0 commented 7 years ago

It's a tricky situation. Cairo is well-maintained but we pull in glib and gtk which is a heavy dependency just for a game engine. Nanovg may be undermaintained but it's extremely lightweight in comparison. If there was a middleground, i.e. using Cairo without the glib/gtk dependency, I think that'd work..

nikita-leonov commented 7 years ago

Interesting. Do you know how gtk is used by Cairo? What I see from various documentation that GTK uses Cairo, but not vice versa. It seems that GTK manages window & surface to draw on, as well as high-level components that are drawn by Cairo, meanwhile Cairo handles low-level drawing logic. It should be easily replaceable by SDL as we already have window & surface as SDL can act as backend for Cairo in the same way as GTK. I am not sure why it depends on GTK, need to dig more.

z0w0 commented 7 years ago

OK to clarify we don't depend on GTK directly, however: