151–160 of 212 posts
Curious if you guys have thought about VR / AR possibilities with GPUI?
Earlier quoted context omitted.
But when you do software rendering you don't need to redraw the entire frame buffer, just the parts that changed, which can be very small even at 8k - e.g. the box of a checkbox being switched
You don't need to redraw the entire framebuffer with GPU rendering, either. It's perfectly possible to do small, partial updates. See for example https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_buff... And https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_part...
"Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework" I'm surprised you did not look at "Dear ImGui", "Noesis", and "JUCE". All three of them are heavily used in gaming, are rather clean C++, use full GPU acceleration, and have visual editors available. Especially JUCE is used for A LOT of hard-realtime professional audio applications. "Wh…
This is not to diminish the quality work that went into the library, but I passed over it for those and other reasons. I used nuklear for a bit since its typography was extensible but in the end it was too hard to overcome its other issues, so I use a custom mixed immediate/retained library now with rich text and accessibility support.
I cannot stress how much I do not want my 300w gpu to be used to render text that change at most three times per second. And it's not just about electricity cost and heat stress, it will conflict with everything else that requires the gpu to do stuff, including watching 4k videos on the second monitor, which does have a legitimate case for requiring hardware acceleration since they move a lot of data 60 times per sec…
I have horrible news to tell you about compositors: they already do use your GPU, even if you're watching a 4K video on the side. Even when requesting a full screen swapchain to avoid having to deal with the compositor, modern OSes will force you to go through that compositor and lie about it being fullscreen. Additionally, using your GPU doesn't mean locking your GPU on that task. Your 4K video most likely isn't tak…
I’m honestly thankful for this bit of lying. Windows 8 and below had horrible, horrible issues with fullscreen programs, especially games - they’d change your screen resolution and thus move and resize all your other windows, they’d freeze for ten seconds when you tried to alt-tab out, and they’d frequently just crash when you switched back to them. Those problems are essentially nonexistent nowadays, and it’s worth the small performance cost that comes from going through the compositor.
"Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework" I'm surprised you did not look at "Dear ImGui", "Noesis", and "JUCE". All three of them are heavily used in gaming, are rather clean C++, use full GPU acceleration, and have visual editors available. Especially JUCE is used for A LOT of hard-realtime professional audio applications. "Wh…
I'm not even sure it was wise to use SDFs to draw some shaded rounded rectangles.
I mostly stick with them because the flexibility and image quality feel worth it.
Earlier quoted context omitted.
Scrolling requires redrawing most if not the whole framebuffer.
With scrolling couldn't you just shift the existing framebuffer up/down and only draw the newly scrolled-to parts?
"Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework" I'm surprised you did not look at "Dear ImGui", "Noesis", and "JUCE". All three of them are heavily used in gaming, are rather clean C++, use full GPU acceleration, and have visual editors available. Especially JUCE is used for A LOT of hard-realtime professional audio applications. "Wh…
When we talk about 2D graphics as a research problem, we're talking about native rendering of splines and strokes. JUCE does not have GPU-accelerated splines, it flattens the path to lines and rasterizes the coverage area into a texture that then gets uploaded to the GPU: https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db... https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db... It also does stroke…
CoreGraphicsContext::createPath will convert the CPU spline segments to CG spline segments which are then rasterized by CoreGraphics using Metal on the GPU.
https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db...
And on Windows 7 and up it'll use the hardware-accelerated Direct2D APIs:
https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db...
Earlier quoted context omitted.
I have horrible news to tell you about compositors: they already do use your GPU, even if you're watching a 4K video on the side. Even when requesting a full screen swapchain to avoid having to deal with the compositor, modern OSes will force you to go through that compositor and lie about it being fullscreen. Additionally, using your GPU doesn't mean locking your GPU on that task. Your 4K video most likely isn't tak…
> Even when requesting a full screen swapchain to avoid having to deal with the compositor, modern OSes will force you to go through that compositor and lie about it being fullscreen. I’m honestly thankful for this bit of lying. Windows 8 and below had horrible, horrible issues with fullscreen programs, especially games - they’d change your screen resolution and thus move and resize all your other windows, they’d fre…
But yes, alt-tabbing Source games was an exercise in patience.
Earlier quoted context omitted.
When we talk about 2D graphics as a research problem, we're talking about native rendering of splines and strokes. JUCE does not have GPU-accelerated splines, it flattens the path to lines and rasterizes the coverage area into a texture that then gets uploaded to the GPU: https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db... https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db... It also does stroke…
You linked to the software fallback renderer which can be used for cross-platform compatibility. But JUCE also has platform-specific rendering modules. CoreGraphicsContext::createPath will convert the CPU spline segments to CG spline segments which are then rasterized by CoreGraphics using Metal on the GPU. https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db... And on Windows 7 and up it'll use the hardware-…
CoreGraphics does not use the GPU.
Direct2D uses a approach which tesselates paths into triangles on the CPU. It is similar to the JUCE code in that the GPU is used for coverage, but it still does not natively render splines on the GPU.