On Sunday, 22 July 2018 at 16:33:10 UTC, Zheng (Vic) Luo 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

I can't say too much about this as I'm not that familiar with the proposed project, but here's what I can say: it's just a suggestion. It's definition isn't set in stone and is just a pointer to a problem to get you started.
For more pointers and discussion, I recommend to ping Mike (https://github.com/JinShil) as IIRC he was the one who proposed this project and could also be a potential mentor.
(and I think the aim is sth. to sth. akin to Skia)

> - 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?

Yes. Applicants aren't expected to be D experts. Also sound experience in C++ will definitely help you (especially for such a low-level project).
AFAICT a sound proposal and showing that you are serious about the project/commitment is more important than your D history.
There are a few posts in the D blog about the GSoC in 2016 (https://dlang.org/blog/category/gsoc) which provide a few more insights, but in short none of the students from GSoC 2016 were well-known member of the D community before the GSoC.

On Sunday, 22 July 2018 at 16:33:10 UTC, Zheng (Vic) Luo 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

I'm JinShil, the one who proposed the idea.

As far as I'm concerned, if you're doing the work, you can make it into whatever you'd like, but I would consider a basic 2D, anti-aliasing rasterizer to be a success.  I have in mind something like http://www.antigrain.com or Skia.  A bonus would be a font renderer that leverages the aforementioned rasterizer (See also https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445).

The software should be efficient enough to use on embedded systems like https://github.com/JinShil/stm32f42_discovery_demo  Under that constraint, you'd probably want to try to accomplish the task with the -betterC-like subset of the language (https://dlang.org/spec/betterc.html).  That being said, there's no reason the software couldn't be used on a PC with resources to spare, and it would probably be easier to do the development on a PC and just verify the implementation on an microcontroller periodically.

I, myself, don't have much experience in graphics, so I don't know if I'd be a very good mentor, but if you have any questions about the goal or use case for the project, let me know.

> - 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?

I think much of your experience with C++ will carry forward to D, but there will still be a learning curve.

Mike

On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote:

> We're also in search of potential mentors and ideas for student projects

I posted a number of different ideas for ROSEdu Summer of Code at https://forum.dlang.org/post/aqlzjjfrwwxswptilgnb@forum.dlang.org.  I believe those ideas could also be considered for Symmetry Autumn of Code.

Mike

On Sunday, 22 July 2018 at 22:07:00 UTC, Mike Franklin wrote:
> The software should be efficient enough to use on embedded systems like https://github.com/JinShil/stm32f42_discovery_demo
>  Under that constraint, you'd probably want to try to accomplish the task with the -betterC-like subset of the language (https://dlang.org/spec/betterc.html).  That being said, there's no reason the software couldn't be used on a PC with resources to spare, and it would probably be easier to do the development on a PC and just verify the implementation on an microcontroller periodically.
>
> I, myself, don't have much experience in graphics, so I don't know if I'd be a very good mentor, but if you have any questions about the goal or use case for the project, let me know.

Thank you for the suggestion. Previously I interned at a VR company and had some experiences writing code related to graphics, but I don't have any experience on embedded system programming, so I was wondering that do I need to buy a microcontroller or just testing it on PC would be enough? If it's the former one, could you give some suggestions on the starter kit?

On 23/07/2018 6:00 PM, Zheng (Vic) Luo wrote:
> On Sunday, 22 July 2018 at 22:07:00 UTC, Mike Franklin wrote:
>> The software should be efficient enough to use on embedded systems like https://github.com/JinShil/stm32f42_discovery_demo
>>  Under that constraint, you'd probably want to try to accomplish the task with the -betterC-like subset of the language (https://dlang.org/spec/betterc.html).  That being said, there's no reason the software couldn't be used on a PC with resources to spare, and it would probably be easier to do the development on a PC and just verify the implementation on an microcontroller periodically.
>>
>> I, myself, don't have much experience in graphics, so I don't know if I'd be a very good mentor, but if you have any questions about the goal or use case for the project, let me know.
> 
> Thank you for the suggestion. Previously I interned at a VR company and had some experiences writing code related to graphics, but I don't have any experience on embedded system programming, so I was wondering that do I need to buy a microcontroller or just testing it on PC would be enough? If it's the former one, could you give some suggestions on the starter kit?

Based upon the repository linked:

https://www.aliexpress.com/item/STM32F429I-DISCO-Embeded-ST-LINK-V2-STM32-Touch-Screen-Evaluation-Development-Board-STM32F4-Discovery-Kit-STM32F429/32754485004.html?spm=2114.search0104.3.254.4f1137329ITDKU&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10344_10068_10342_10547_10343_10340_10059_10341_10548_10696_100031_10084_10083_10103_10618_10307_10624_10623_10622_10621_10620,searchweb201603_1,ppcSwitch_2&algo_expid=bee79865-7735-4b46-8010-a905be82e0e4-40&algo_pvid=bee79865-7735-4b46-8010-a905be82e0e4&priceBeautifyAB=0

As long as it has a touch screen, programmer (ST-LINK) and STM32F429I chip on board, you should be good to go for those instructions.

Of course that isn't a cheap board, and you may want to put some work into instead of paying for it ready to go, and get one of the blue pill (stm32f104) boards ($10 will cover programmer + board, another $10 for touch screen).

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?
>>
>> Thanks
>
> 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.

On Monday, 23 July 2018 at 06:00:14 UTC, Zheng (Vic) Luo wrote:

> Thank you for the suggestion. Previously I interned at a VR company and had some experiences writing code related to graphics, but I don't have any experience on embedded system programming, so I was wondering that do I need to buy a microcontroller or just testing it on PC would be enough? If it's the former one, could you give some suggestions on the starter kit?

Well, I won't be the one paying you, and I don't think I'll be the one evaluating your work, so I don't think my opinion matters, but as the one who proposed the idea, I'll just explain my point of view.

Microcontrollers have limited CPU and memory resources.  Generally, they operate by filling a dedicated buffer in RAM (width * height * pixel_format_size) with pixel data.  The size and format of the pixel data is generally decided at compile-time based on the needs of the application.  Some microcontrollers have a dedicated hardware peripheral to aid in the blitting and blending of pixel data, but most don't.  So, for all intents and purposes, this project is a software rasterizer in D; you definitely won't find any CUDA cores here.

Understanding the capabilities and limitations of the microcontrollers will give you some perspective and understanding about the design tradeoffs you will most certainly need to make, but, once you have that perspective, in the end, you're just filling a buffer with pixel data, and I don't see why one couldn't do the vast majority (if not all) of development for that on their PC.

That being said, getting a low-speed MCU with as little memory as 256KB animating an LCD display can be a thrilling experience.  If you're interested, I suggest obtaining one of the STM32 Discovery Kits with a built-in LCD screen.  See https://www.st.com/en/evaluation-tools/stm32-mcu-discovery-kits.html?querycriteria=productId=LN1848 (Typically one ofSTM32F4 or STM32F7 models)

This is the one that I have, and it only costs about $30:  https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html#samplebuy-scroll  Furthermore, I've already created the platform code for you at https://github.com/JinShil/stm32f42_discovery_demo, so you should just need to import your library to main.d and try it out.

Mike

On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:

> 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.

There is more to this project than just getting a software rasterizer in D.  Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming.  D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C.

So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating.  This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code.

So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point".  You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal.

Mike

On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote:

> You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal.

Yikes! too many typos there.  It should say...

You can put those software building blocks in their own module, and let the user of the software rasterizer library link in their own implementation if they wish to deviate from the spirit of the proposal.

Mike

On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:

> Should we assume a multi-threading model?

I say, no.  To get threads on microcontrollers, you typically first need to implement a Real-time Operating System (RTOS).  If you want to implement an RTOS in D, and then build the rasterizer on that, that would be very cool!....but also very challenging ;-)

Mike