tekknolagi / full-beans

https://bernsteinbear.com/blog/fenster-microui/
MIT License
166 stars 6 forks source link

High CPU usage #4

Open CardealRusso opened 1 week ago

CardealRusso commented 1 week ago

What causes the high CPU usage?

akkartik commented 1 week ago

It's a good question; I see it now. My CPU is pegged at close to 100% (of one core).

Neither fenster nor microUI with SDL are this inefficient.

Even if I drop down from 60fps to 10fps, it still quickly ramps up to 30% CPU core.

I did a quick profile with gprof, and it looks like this:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
 27.58      1.93     1.93                             mu_color
 21.87      3.46     1.53                             blend_pixel
 16.65      4.63     1.17                             r_color
 10.00      5.33     0.70                             flush

Looks like it's because of our extremely naive purely-CPU shading. We're basically recomputing the color of each pixel even when drawing rects with a constant color.

One confound here is that we sometimes need to blend the white from the font within the rect. But perhaps we can get by with a 2-color cache.

Anyways, I've turned on compiler optimizations (-O3) and disabled assertions (-DNDEBUG) and it seems to be running at 30-40% CPU core. So that's something.

tekknolagi commented 1 week ago

There's another project that does caching using microui. I'll see if I can find it later and distill the core of it into this as an optional addon

On October 3, 2024 11:07:53 AM EDT, Kartik Agaram @.***> wrote:

It's a good question; I see it now. My CPU is pegged at close to 100% (of one core).

Neither fenster nor microUI with SDL are this inefficient.

Even if I drop down from 60fps to 10fps, it still quickly ramps up to 30% CPU core.

I did a quick profile with gprof, and it looks like this:

Each sample counts as 0.01 seconds.
 %   cumulative   self              self     total           
time   seconds   seconds    calls  Ts/call  Ts/call  name    
27.58      1.93     1.93                             mu_color
21.87      3.46     1.53                             blend_pixel
16.65      4.63     1.17                             r_color
10.00      5.33     0.70                             flush

Looks like it's because of our extremely naive purely-CPU shading. We're basically recomputing the color of each pixel even when drawing rects with a constant color.

One confound here is that we sometimes need to blend the white from the font within the rect. But perhaps we can get by with a cache.

Anyways, I've turned on compiler optimizations (-O3) and disabled assertions (-DNDEBUG) and it seems to be running at 30-40% CPU core. So that's something.

-- Reply to this email directly or view it on GitHub: https://github.com/tekknolagi/full-beans/issues/4#issuecomment-2391666559 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

CardealRusso commented 6 days ago

-flto cuts cpu usage by almost half But it's still not practical, as usage should remain at 0~1%.

Pixels are unnecessarily updated every frame.