Offer: Update interface on Demand

[Lexi4]

At the moment I am considering a laptop as a workstation for writing shaders. But your editor updates the entire interface constantly, thereby loading the video subsystem by 100% on the built-in graphics of Vega 8. It would be very cool if the interface, or its elements were updated on demand, as is done in Blender, thereby without constantly loading the video chip while writing the code or the absence of any actions, including when stopping the preview. This will have a very positive effect on energy consumption.

Notebook specs: APU: AMD Ryzen 5 3500u with Vega 8 Integrated graphics Display: 2160x1440px RAM: 16gb ddr4

[Lexi4]

[dfranx]

You could just turn on the vsync or set the FPS limit and apply it to the whole application

[Calinou]

@dfranx Applying a FPS limit will make the application feel less smooth and reactive, so it's only a partial workaround. In contrast, Blender avoids redrawing when nothing on screen has changed, but it doesn't apply a FPS limit per se.

[Lexi4]

I totally agree with @Calinou Making the program work economically is only possible at 10fps, which is clearly not enough when writing code and creates severe discomfort. Otherwise, you have to deal with an increase in temperature, noise from coolers, extremely high (up to 3 times) power consumption.

[dfranx]

@Lexi4 @Calinou Now that I think about this, not sure how comparable SHADERed is to Blender. Shaders can create very dynamic scenes; for example, the InstancedCompute project in examples/ directory - every frame is different from the previous frame & there's no way for me to detect if previous frame == current frame without adding some kind of overhead (checking if output textures of the two frames match, also that would slow down SHADERed significantly, I think) and without rendering curent frame. So even if I manage to make the user interface update only when necessary I'd still have to render the preview window's content. That would still cause your GPU utilization to go to 100% since the GPU will try to render those frames as fast as possible. While the CPU FPS limit option in SHADERed is not perfect and may cause the app to feel less smooth, VSync option should be okay on the other hand..

I'd say SHADERed is more comparable to a game - there's no way to pump more frames without power consumption going up and also every frame is different from the previous frame.. The only solution is probably limiting FPS with vsync or similar options.

Not sure, maybe my thinking is completely wrong though?

[Lexi4]

@dfranx I see a solution to the problem in the following version: Rendering the interface in one render thread Drawing the viewport in a separate render thread. In this case, the interface is rendered only if a change was received (moving the cursor in the code, hovering the mouse over the button), and not a certain number of times per second And the rendering of a viewport with a scene or shader occurs constantly, but at the same time it is possible to pause it, thereby not rendering in the render thread of the viewport during the pause. However, this pause should not affect the render flow of the interface.

With this option, the frame limiter will affect only the viewport's render thread. The interface will be rendered on demand (on any changes). At the same time, if you pause the render thread of the viewport, the load on the GPU should be close to zero, rising only slightly during episodic rendering in the interface thread

[dfranx]

Ah okay, I'll leave this open if I ever decide to implement something like this. It currently seems like way too much work when, as I mentioned, VSync pretty much does the job. SHADERed used ~90% on my GTX 1050 Ti when vsync was turned off, but when I turned it on the usage dropped to <15%.