I am the presenter in the video. I am here to answer any questions about 2d graphics, Nim programming language, performance and testing. Thank you for watching!
Hi, thanks a lot for the presentation, it was very interesting. I'd have a few questions :
1) Why choose a CPU approach ? The trend seems to be doing 2D graphic on GPU (for e.g Mozilla's WebRender or Google / Raph L. 's Piet-GPU).
2) Is Pixie going to be the rendering lib for Fidget ? If it is the case, do you think the perfs / battery usage will be okay despite the drawing being done on CPU ?
3) I loved your last presentation on Fidget. What's going to be the main changes in Fidget 2 ? Are you still going to be using a Virtual DOM ? How/where do you store the app states ? I'd be very interested in any early info you could share about it
1) Why CPU? Mainly we used CPU because it's easier to get working. A lot of this graphics stuff requires deep understanding. It’s just easier to get CPU mode running. I do have many GPU experiments though. I even have a macro that translates a subset of Nim into the GLSL - GPU’s shader language. In time if the GPU path becomes better we will switch to it.
2) Yes, Pixie will render Fidget. Current system is that Pixie renders to a texture atlas. Then Fidget just deals with the textures. Pixie does work only at “load time” or when a new element comes on screen. For most screens Pixie CPU rendering will not be called that often. At this time the CPU render for text is faster than my on-the-GPU render. More things will switch to GPU as it becomes faster.
3) I am still working on Fidget, but I really wanted to get Pixie done first. I have this idea that I am exploring. But I don’t have anything for sure yet. One thing for sure Fidget 2 will be a total paradigm ship from Fidget 1. But Fidget 2 is still ways off.
Co-author here, I worked a bunch on the SIMD stuff in Pixie which I have really enjoyed. If anyone is curious about SIMD or anything else I'll be around.
Pixie is super cool - I recently spent some time getting it up and running on the 3DS and was shocked at how easy it was. I only needed to do a single code change and everything just... works. Granted CPU rendering on the 3DS is pretty slow, as it isn't known for its speed, but it is super cool that I could write Nim code and draw stuff on it in a platform agnostic way.
Eventually I'll get around to rewriting one of my projects (a visual novel engine) to use it for better 3DS support, and so that I can get a lot of the benefits of Nim.
7 comments
[ 4.5 ms ] story [ 26.2 ms ] thread1) Why choose a CPU approach ? The trend seems to be doing 2D graphic on GPU (for e.g Mozilla's WebRender or Google / Raph L. 's Piet-GPU).
2) Is Pixie going to be the rendering lib for Fidget ? If it is the case, do you think the perfs / battery usage will be okay despite the drawing being done on CPU ?
3) I loved your last presentation on Fidget. What's going to be the main changes in Fidget 2 ? Are you still going to be using a Virtual DOM ? How/where do you store the app states ? I'd be very interested in any early info you could share about it
2) Yes, Pixie will render Fidget. Current system is that Pixie renders to a texture atlas. Then Fidget just deals with the textures. Pixie does work only at “load time” or when a new element comes on screen. For most screens Pixie CPU rendering will not be called that often. At this time the CPU render for text is faster than my on-the-GPU render. More things will switch to GPU as it becomes faster.
3) I am still working on Fidget, but I really wanted to get Pixie done first. I have this idea that I am exploring. But I don’t have anything for sure yet. One thing for sure Fidget 2 will be a total paradigm ship from Fidget 1. But Fidget 2 is still ways off.
Eventually I'll get around to rewriting one of my projects (a visual novel engine) to use it for better 3DS support, and so that I can get a lot of the benefits of Nim.