Osu: Cursor trail performance

[carmonben]

When I decrease the number of cursor trail parts stored, i improve minimum framerates and maximum frametimes by upwards of 20% on high end hardware

The numbers I used were the default of 2048 vs 128
128 was chosen because I could not see a difference in cursor trail between 128 and 2048, but i could see a difference between 128 and 64 (it was shorter)

[carmonben]

This decreased the number of drawn triangles from about 12k to about 1.5k for the cursor

[peppy]

Please create a testcase which shows how you benchmarked this. It should be based on a static method which we can also test.

[peppy]

Renaming from "culling issue" because it's not.

[carmonben]

I played the map Viva la Vida hard difficulty with auto, and started recording frametimes after the circle in the center dissappeared, then ended recording when the timer on the bottom right hit 0:00

[carmonben]

And it is technically a culling issue because polygons that are not visible are being rendered

[peppy]

We can't really do anything without making test cases with actual visual comparisons. As it stands, none of your frame times brought the game loop below 60hz, and the 0.1% lows you see could have been triggered by anything imaginable.

[carmonben]

Numbers were captured using msi afterburner's benchmark tool, and with the in-game framerate counter disabled

[carmonben]

You want the fps to be at least twice the refresh rate of your monitor and these frametimes are pretty far from that on even a 144hz monitor, much less a 240hz one

[carmonben]

Besides it is invisible polygons, and you don't want to render invisible polygons no matter what you are doing

[peppy]

I'm not saying otherwise, but your benchmarks here are useless. The cursor trail needs to be isolated and tested visually and for performance. If you can't do this, please stop commenting until someone who can does so.

[peppy]

On a quick test, the overhead of a full length trail (with all 2048 segments showing) is around 0.04ms on draw and 0ms on update.

Furthermore, 128 visually changes the trail to a point of it almost not displaying at all:

vs

[carmonben]

After running a few tests i determined that the update time was unaffected, as were draw times were on 1070 (it was within margin of error {20-50 fps drop out of 1.5k}), but with integrated graphics, I saw the same drop, 180-150 fps with cursor trail 128 down to 130-90 with 2048, this appears to use the memory of the gpu, and hurts integrated graphics more than dedicated graphics, I'm going to test lower end integrated graphics next because I think not having any dedicated memory will make this issue even more pronounced [citation needed]