> ... 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 to recreate the texture every frame, instead of once for multiple frames. So "It might use more CPU" is quite certainly true.
You can also do some simple math to arrive at a justification:
Assume a 4k x 2k display at 60 FPS.
Compute the throughput needed (Bytes per second) to draw an RGB framebuffer.
That is: 8M pixels x 3 Bytes x 60 fps = 1.44 GB/s
Note how we haven't done any computation yet to decide what the colours should be, this is just the CPU effort to do IO to tell the GPU about the new colours to show.
This would incur significant CPU usage, and your device would get hot quickly. In contrast, if you let the GPU scroll, you have to send two floats (for X and Y offset) per frame, and the GPU just does a hardware-parallelised lookup.
This is why we have GPUs, and why scrolling immediate-mode would make your device burning hot while a GPU does the task with minimal energy usage.
Following the same logic that you use... have you calculated how much memory do you need to store the memory of a single treeview, or a single scrolling document of just several pages?
Two floats? You are using a memory that is a CPU memory, a big chunk of memory. That does not exist in the GPU. In the GPU the memory is distributed so it can be used in parallel.
Immediate GUI exist because of GPUs, because with GPUs you can draw frames fast. If you look at Imgui code it uses GPU drawing for everything. In fact it uses only two drawing functions copying small rectangles in the screen.
It is drawing a single big chunk of memory what is extremely slow, and you need to do that before you do offsetting.
And if you work with variable data, like a treeview, you need to allocate for a finite amount of memory in the GPU buffers.
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 for drawing text because it is extremely slow generating this texture and it is not flexible.
Those companies in the bleeding edge, they draw directly in the screen from curves like bezier approximations.
The GPU doesn't need to read texels or calculate fragments that aren't visible.
So, every frame it is only copying the visible chunk of the scrollable buffer to the framebuffer. GPUs are efficient at that. More expensive rendering to the scrollable buffer, when it is either static or infrequently changing, can be as-needed instead of every frame.
That's a really well-favored set of trade offs for many cases where you need smooth scrolling.
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.
An immediate mode GUI doesn't have to use immediate mode rendering. For example, the Dear ImGui library "outputs optimized vertex buffers that you can render anytime in your 3D-pipeline enabled application." [0]
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 to recreate the texture every frame, instead of once for multiple frames. So "It might use more CPU" is quite certainly true.