5 ms·
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 graphi
by kujino 5y ago
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
- treeform 5y ago1) 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.
- kujino 5y agothanks for the answer , all the best for your future works