Closed creikey closed 2 years ago
Thank you for the issue. I don't think we are going to do this in the near future. This is quite hard to do well, and probably unnecessary.
Doing CPU and GPU vector graphics every frame is just slower then doing CPU or GPU vector graphics once and uploading a raster image to the GPU. See:
That's exactly why we made boxy: https://github.com/treeform/boxy
Saving a couple of seconds from a run of the whole program just does not interests us that much.
Thank you for the issue. I don't think we are going to do this in the near future. This is quite hard to do well, and probably unnecessary.
Doing CPU and GPU vector graphics every frame is just slower then doing CPU or GPU vector graphics once and uploading a raster image to the GPU. See:
That's exactly why we made boxy: https://github.com/treeform/boxy
Saving a couple of seconds from a run of the whole program just does not interests us that much.
Are the draw calls for the gpu rendering batched? Pretty much every application that I've worked on requires more than just static atlases moving around the screen, the window is expected to resize often instantly, text is edited often so those images are being refreshed always, etc.
The boxy atlases are dynamic, they have to be. You draw all of your UI components and graphics into separate images in the atlas. If some of them change you update the dynamic atlas images. Even with text you should only update the edited parts.
In our testes this produces 144hz+ UIs even when resizing windows or editing text.
Hey, I am going to close this, as the we would like to keep Pixie simpler and CPU only library. For GPU acceleration we have Boxy. Please use that library.
I am happy to give advice on how to make your specific app performant with pixie+boxy. I don't think the "cairo-gl direction" is worth it.
Like
cairo-gl