121–128 of 128 posts
Earlier quoted context omitted.
Qt's QML uses OpenGL and can at least render into an FBO in your existing OpenGL context more or less out of the box. Integrating it with a game render loop deeper should be possible too, but more effort.
Qt is moving into a 3D API agnostic backend.
> ... people scroll almost constantly in which case the ImGUI wins by a landslide I think this is a misrepresentation of how fast scrolling is usually implemented. For fast scrolling, you render the page (which is larger than the viewport = "what fits on the monitor") ONCE onto a GPU texture, and then all scolling happens on the GPU side (the CPU just tells the GPU the offsets into that texture). Immediate mode has t…
If you have to create a big texture for the GPU, this is the definition of slow. One of the big advantages of drawing for every frame is that you only need to draw what is visible. And do it in real time, with no perceived lag. For a text editor I use I only draw at any given time 1/10.000 of what is actually there. In fact, you don't need to draw textures at all with the GPU, Apple or Microsoft or Google does not do…
That's a really well-favored set of trade offs for many cases where you need smooth scrolling.
Earlier quoted context omitted.
Games (normally) re-render the whole scene every frame. ImGUI exposes that to their API users: you have to re-render and check for clicks on every frame. The code looks like React, (but not as optimized, it re-renders every frame!), and normally you have to keep state by yourself. Code example: [1]. Retained Mode is closer to the DOM, Cocoa or WPF: you create objects and there's an abstraction between the API and the…
> Games (normally) re-render the whole scene every frame They don't re-upload the whole scene to the GPU every frame, they don't recreate objects all the time. Immediate mode was only used in, like, the GL 1.x times.
Earlier quoted context omitted.
This is referring to Electron for the (PC-based) editor UI, not the deployed game UI. (Plenty of criticisms of Electron still hold, of course.)
Ah, that's fair. Unity launched in 2005. Electron released in 2013. Still, saying Unity would have been "better served" by using Electron is more than a little unreasonable! Using a primarily JavaScript environment for primarily C# content sounds like an absolute nightmare to me.
Didn't Firefox put forward a big plan to basically implement the browser as an immediate mode UI designed to redraw everything on every frame?
WebRender is not just a "plan" but a real thing (I'm using it right now), and it's fully retained. Immediate doesn't mean just redrawing everything on every frame, immediate means what's described in the article — not keeping state. WR aggressively relies on kept state to optimize rendering of each frame as much as possible.
Earlier quoted context omitted.
No need to malloc each frame. Malloc at startup and memset each frame (don't even need to do that, tbh).
Nope, just set the pointer back to where it started from. You do need to be super careful doing this though, as anything that relies on RAII (in c++ land) will be busted. You could manually call the destructor on the object in that case, but kind of defeats the purpose of the "no allocation" goals
Earlier quoted context omitted.
I think you're conflating the IMGUI versus RMGUI question with whether rendering is done on the CPU or GPU. The two questions are independent of one another.
I don't think so: Full immediate mode rendering on the GPU would require scene graph and application logic on the GPU. People don't do that stuff in shaders or CUDA, because they were neither designed for it, nor is it fast, nor is it pleasant to code.