Run 'update' on components at most every 200ms

[MeeniMc]

When using this addon with a very strong graphic card and {sodium,optifine), the better F3 screen measures a much lower FPS than the normal F3 screen. For example, with Sodium, I observe ~300fps in game, ~290fps in the F3 screen, ~100 fps in the BetterF3 screen.

I believe the problem is that the addon runs the 'update' method for every frame, which is a massive overkill, and apparently cannot achieve better than 100fps. Running the update (or, doing something in the method) at most 5 times per second should be plenty enough.

[cominixo]

I've tried reducing the number it updates, and it doesn't seem to help much performance-wise, I'll try it again though since I haven't looked much into it, since the vanilla debug HUD also updates every frame. The rendering probably takes a bit of the performance too though, because the vanilla debug HUD is only rendering a String.

[MeeniMc]

You should cache the string (colors and all included) and return the same string for every update call until some 100/200 ms have elapsed.

[MeeniMc]

I tried to improve perf myself. I reduced string update rate to every 50ms (caching the arraylist strings in the object), and that improves performance some, but not as much as I hopped.

It appears that the fill method to draw the bgcolor is one of the main performance hogs, removing it from the render method does get a sizeable fps increase.

There is still something else. Looking for ideas I compared the code with malilib, from minihud. Masa does almost the same thing (notably computing the size of the textbox for every line individually at every frame, which I thought was the rest of the cost, but his variant does the same, and still runs almost 30% faster than the variant I created with capped updates and removal of fill bgcolor).

[cominixo]

Yeah, I was just trying moving the updates to a separate thread, not much of a help either, malilib might be worth looking into

[MeeniMc]

Here are my current numbers: (looking at the empty sky, Sodium-next, 4k, most probably fillrate limited) No hud: ~300 fps MiniHud (5 lines with alpha bg: FPS, time, IG time, biome, pitch): ~300 fps Vanilla F3 screen: ~296 fps BetterF3: ~189 fps BetterF3/50ms (my variant updating the strings only once per game tick): ~210 fps BetterF3/1000ms (same but pushing it to absurd to have some ceiling): ~215 fps BetterF3/50ms/nofill (bgcolor does not work anymore): ~245 fps BetterF3/50ms/nofill+refactoring the for loop to move variable initialization outside and remove some .get(i) accessors: ~255 fps

I think the main problem is that the strings issue a separate render call for each individual one. It may be better to create a single string buffer and issue a single Draw() call, or find a way to batch the Draw calls and issue a single commit call to Open GL, but this is getting outside my knowledge zone.

[cominixo]

Yeah, I don't think it's possible to draw everything with one call with the way that Minecraft does text drawing (won't render newlines afaik), but batching might be worth a try

[MeeniMc]

A similar issue gets discussed in this Sodium issue: https://github.com/CaffeineMC/sodium-fabric/pull/727

[MeeniMc]

This mod https://github.com/tr7zw/Exordium helps reduce this issue greatly but it would still be great it BetterF3 by itself would have improved performance.

[MeeniMc]

Immediately fast resolves that issue almost entirely.

[MeeniMc]

This issue tracker is not primary anymore