Hi,
suppose you want to write an application, like text editor or file explorer. And you want to support multiple OS-es? Wouldn't software renderer like the one Casey wrote be ideal? You write it once and it works everywhere. So we are talking about applications that dont have that many sprites, that are not alwalys full screened, run at lower frame rate (30?) and probably don't use too many fancy effects which you need shaders for. How much work do you think you can offload to it before it slows the app down? And what would be features that I can immediately cross because the renderer would be too slow?
I hope this is not too generic question.
Thanks
Vjekoslav
suppose you want to write an application, like text editor or file explorer. And you want to support multiple OS-es? Wouldn't software renderer like the one Casey wrote be ideal? You write it once and it works everywhere. So we are talking about applications that dont have that many sprites, that are not alwalys full screened, run at lower frame rate (30?) and probably don't use too many fancy effects which you need shaders for. How much work do you think you can offload to it before it slows the app down? And what would be features that I can immediately cross because the renderer would be too slow?
I hope this is not too generic question.
Thanks
Vjekoslav
Edited by Vjekoslav
on
Reason: Initial post
Hi vjekoslav,
Unfortunately it is not your question that is too generic, but rather the term "applications"! To be fair, you did mention text editing and file explorers. Learning wise, the best thing one could do is write a software renderer and use it for one's app until it's no longer useful... Then you'll have built up intuition around limitations. I go straight for OpenGL (and I guess Vulkan at some point soon), so I haven't actually followed this advice.
A simpler path is to find a reputable open-source project and see if it has multiple rendering fallbacks. Force it to go into the different modes. It's what I usually do to understand the tradeoffs more.
vurtun's nuklear has an impressive number of render targets for its demo program here -- one example even goes straight for a raw framebuffer! It's not too hard to crank up the number of things a demo does. Then, start profiling. It would be a fun experiment... if you do it, please share your results!
Unfortunately it is not your question that is too generic, but rather the term "applications"! To be fair, you did mention text editing and file explorers. Learning wise, the best thing one could do is write a software renderer and use it for one's app until it's no longer useful... Then you'll have built up intuition around limitations. I go straight for OpenGL (and I guess Vulkan at some point soon), so I haven't actually followed this advice.
A simpler path is to find a reputable open-source project and see if it has multiple rendering fallbacks. Force it to go into the different modes. It's what I usually do to understand the tradeoffs more.
vurtun's nuklear has an impressive number of render targets for its demo program here -- one example even goes straight for a raw framebuffer! It's not too hard to crank up the number of things a demo does. Then, start profiling. It would be a fun experiment... if you do it, please share your results!
Edited by Abner Coimbre
on
Reason: Initial post.
Software rendering for such cases will plenty sufficient. But there is another metric you should think of, not just performance. That is power consumption. Using GPU in most of cases will use less power, which directly translates to less heat and more battery life. Not so important for desktop, but could be quite an important factor for laptop/tablet/mobile users.
Thanks for answers!
Regarding power consumption, I suppose it could be written such as that renderer does not render into backbuffer if state didn't change. Since applications mostly respond to user's input. Render API could still remain immediate mode, but the renderer would ignore render commands if everything is the same. Further optimizations could probably be written, like invalidated draw regions. Suposse your app has 2 panels, if you change something in left one, you dont need to redraw right one. At this point things seemed to be getting complicated, but maybe it would be worth while if it saves you implementing different graphics APIs for each OS. It seems like a good tradeoff for apps, does it not?
Regarding power consumption, I suppose it could be written such as that renderer does not render into backbuffer if state didn't change. Since applications mostly respond to user's input. Render API could still remain immediate mode, but the renderer would ignore render commands if everything is the same. Further optimizations could probably be written, like invalidated draw regions. Suposse your app has 2 panels, if you change something in left one, you dont need to redraw right one. At this point things seemed to be getting complicated, but maybe it would be worth while if it saves you implementing different graphics APIs for each OS. It seems like a good tradeoff for apps, does it not?
Edited by Vjekoslav
on
now you are describing most desktop applications pre hardware acceleration.
The typical widget-based gui framework will do exactly that: keep the pervious frame for display and only redraw what the OS needs redrawn or the user code tells it to have redrawn.
The typical widget-based gui framework will do exactly that: keep the pervious frame for display and only redraw what the OS needs redrawn or the user code tells it to have redrawn.
Yeah I suppose. But is that a bad thing? Doesn't custom renderer still outwins widget-based gui toolkits like QT?
Because:
a) It's should be easier to do custom stuff with graphics if you need to. You're not constrained to widgets that toolkit provides you with.
b) A lot of these toolkits are huge, bloated and some of them are even pricy.
Because:
a) It's should be easier to do custom stuff with graphics if you need to. You're not constrained to widgets that toolkit provides you with.
b) A lot of these toolkits are huge, bloated and some of them are even pricy.
Hello Vjekoslav,
Everything has been saved above: your CPU will consume so much more power than the GPU that the saving in programming time isn't worth the loss of performance/power consumption. From what I measured long ago, anything above 800x600 and your CPU will be spending too many cycles it could use to do something more useful, or just save power.
Even if you need to implement a hardware renderer several times, all you need for a GUI-application is being able to draw some colored and textured quads, it's not like you have to rewrite Unreal Engine 4's renderer and port it to several platforms. And if you care so little about performance that you were considering a software renderer, writing an naive unoptimized hardware renderer will still outperform it.
Abner made the same point using nuklear; I'm more familiar with Dear ImGui and its samples implement just enough of the graphics API to be able to display any GUI component, you can use them as a starting point for your GUI application without modifying the renderer code!
What Casey did in Handmade Hero's first renderer has value in that it shows us that computers nowadays are vastly overpowered, compared to the performance the software we use can make us believe. That doesn't mean shipping an application with a 16-thread software renderer is a sensible idea!
Regarding your last post, these points don't seem related to comparing software- and hardware-rendered GUI applications, but just that some GUI libraries are closed-source or too bloated to be modified?
Everything has been saved above: your CPU will consume so much more power than the GPU that the saving in programming time isn't worth the loss of performance/power consumption. From what I measured long ago, anything above 800x600 and your CPU will be spending too many cycles it could use to do something more useful, or just save power.
Even if you need to implement a hardware renderer several times, all you need for a GUI-application is being able to draw some colored and textured quads, it's not like you have to rewrite Unreal Engine 4's renderer and port it to several platforms. And if you care so little about performance that you were considering a software renderer, writing an naive unoptimized hardware renderer will still outperform it.
Abner made the same point using nuklear; I'm more familiar with Dear ImGui and its samples implement just enough of the graphics API to be able to display any GUI component, you can use them as a starting point for your GUI application without modifying the renderer code!
What Casey did in Handmade Hero's first renderer has value in that it shows us that computers nowadays are vastly overpowered, compared to the performance the software we use can make us believe. That doesn't mean shipping an application with a 16-thread software renderer is a sensible idea!
Regarding your last post, these points don't seem related to comparing software- and hardware-rendered GUI applications, but just that some GUI libraries are closed-source or too bloated to be modified?
vjekoslav
Yeah I suppose. But is that a bad thing? Doesn't custom renderer still outwins widget-based gui toolkits like QT?
Because:
a) It's should be easier to do custom stuff with graphics if you need to. You're not constrained to widgets that toolkit provides you with.
b) A lot of these toolkits are huge, bloated and some of them are even pricy.
Widget toolkit are going to have at least 1 widget that enables custom drawing which allows more lightweight gui element or something that doesn't fit in the widget model. I've used that myself to create a drag and drop interface and a graph without trying to make my graphical objects widgets in their own right.
Also widget frameworks tend to have features that are important when targeting non-standard people. For example integration for screen-readers, support for rtl text, etc.
Is there an easy way to measure power consumption of an application (on Windows and Linux) ? I've started to work on a software renderer for my own small tools and would like to be able to measure the impact it has.
On Linux you can get power usage of system by reading /sys/class/powercap/intel-rapl:*/energy_uj file. It won't be per application, but it will allow to measure how it changes if you run something or not. There are bunch of cli/tui tools that displays this value in more friendlier way as used Watts, for example, s-tui or powerstat. I'm sure there are also GUI tools for this, but I have not used any.
Here's some useful documentation on rapl:
https://01.org/blogs/2014/running-average-power-limit-%E2%80%93-rapl
http://web.eece.maine.edu/~vweaver/projects/rapl/
No idea about Windows, I did not have need to measure power there.
Here's some useful documentation on rapl:
https://01.org/blogs/2014/running-average-power-limit-%E2%80%93-rapl
http://web.eece.maine.edu/~vweaver/projects/rapl/
No idea about Windows, I did not have need to measure power there.
Edited by Mārtiņš Možeiko
on