On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote:
I'm interested in the "Graphics library for resource constrained embedded systems" project and have some spare time this autumn, but I have some questions: - Does this project aim at creating a hardware-agnostic rasterizer supporting a few primitives like https://skia.org/ or implementing a full GUI library like emWin rendering widget and handling I/O events such as mouse? The latter one sounds a little bit challenging to finish in four months - In the past year I primarily wrote C++ and don't have much experiences with production-level D programming, can I get involved into this program?


IMHO no need to reinvent the wheel for that.

You can probably do both in four months, if you just "port" (separately) and bind the code of the two following libraries :
1/ swGL (https://github.com/h0MER247/swGL)
2/ Nuklear (https://github.com/vurtun/nuklear)

They have a very open design, and are already quite well optimized for speed and memory consumption.

Moreover this would allow the D port of the Nuklear library to also use a hardware accelerated renderer on desktop platforms.

Nice isn't it ?

And I'd be glad to mentor you on this :)

Thanks! Porting seems to be easier than creating a library from scratch. The Nuklear library looks like a great candidate for porting since it only has a few external dependencies. swGL, however, depends on a large set of C++ standard library and threading model, which makes it difficult to create a dependency-free port.

Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming.

Reply via email to