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.
Comments
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.
thanks for the answer , all the best for your future works