Status bar caching - any point?

[Quasar]

EE still wastes a lot of memory and code maintaining the cached status bar in the way it was handled in vanilla. I'm wondering if there is any use or advantage to this in the present day, or if we should do away with it right now before adding any kind of status bar customization abilities.

[DaniJ]

I honestly cannot think of any good reason to continue doing it the way it was implemented in vanilla given you want to extend customization of it.

[andrewj]

I doubt that caching stuff made much difference even back in the days of the 486.

For your own sanity and happiness, toss it asap.

[entryway]

andrewj said:

I doubt that caching stuff made much difference even back in the days of the 486.

Full refreshing is noticeable slower. At least for prboom.

epic.wad map05 640x480
285*100/270 = 105.6% -> +5%

epic.wad map05 1024x768
186.7*100/172.5 = 108.2% -> +8%

doom2.wad map12 640x480
1468*100/1183 = 124.1 -> +24%

[Graf Zahl]

What are these values? I'm guessing FPS but I'm not sure. Just throwing around random numbers without reference is useless.

The only valid information here is drawing time in milliseconds.

That said, I doubt that this has any real world benefit whatsoever unless you are an FPS whore and the difference between something like 250 and 260 actually matters.

So, if Entryway's numbers are really FPS, let's try to convert this to milliseconds.

So:

285 fps == 3.5 ms
270 fps == 3.7 ms

1468 fps == 0.68 ms
1184 fps == 0.85 ms

And for a larger screen:

186.3 fps == 5.35 ms
174.5 fps == 5.73 ms

So redrawing the status bar completely costs 0.2 ms on 640x480 and 0.4 ms on 1024x768.

Also, saying what kind of system you use would also help.

[entryway]

Graf Zahl said:

What are these values? I'm guessing FPS

yes

Graf Zahl said:

Also, saying what kind of system you use would also help.

Core2duo 3.0 GHz

[RjY]

I have an Athlon 64 3200+ from 2005. Using PrBoom trunk with the command line

prboom -config /dev/null -window -timedemo demo2

gave timings of

Timed 2001 gametics in 404 realtics = 173.4 frames per second

and

Timed 2001 gametics in 445 realtics = 157.4 frames per second

first with, and then without, difference drawing*. Repeating the tests gave very little variation (+/- 3 realtics)



My view is that you might as well keep it, unless it makes it too hard to make other changes you want to make to your status bar code, in which case it won't make an incredible difference if you get rid of it. I personally took it out of my own engine because it got in the way of other things I wanted to do, and I left it out because its removal didn't seem to make enough of a difference for me to care. But then I don't use uncapped framerate so perhaps I am not the best person to comment.

I think you just have to weigh the cost of maintaining it in light of whatever changes you're planning against the performance loss, and make a decision.



* the precise change was as follows

@@ -851,3 +851,3 @@ void ST_Drawer(boolean statusbaron, boolean refresh)
   if (statusbaron) {
-    if (st_firsttime || (V_GetMode() == VID_MODEGL))
+    if (1 || st_firsttime || (V_GetMode() == VID_MODEGL))
       ST_doRefresh();     /* If just after ST_Start(), refresh all */

[entryway]

Graf Zahl said:

The only valid information here is drawing time in milliseconds

Of course no. The only useful information is percentage. If I'll have Pentium 10 or Core150Peta and drawing time in milliseconds of something will be 0.0001ms, then it does not mean that optimization of 'something' is useless, because that 0.0001ms can eat 80% of time and FPS on slow machine can be dropped from 60 to 10. That 8% for 1024x768 is really big difference and it will be very hard to find an another place for such big improvement. And I am not talking about that 24% improvement on simple level (because epic.wad is hard for processing itself), which obviously is extremely useful. That's nice example how 40 unplayable fps are going to 60.

[Graf Zahl]

entryway said:

Of course no. The only useful information is percentage. If I'll have Pentium 10 or Core150Peta and drawing time in milliseconds of 'something' will be 0.0001ms, then it does not mean that optimization of 'something' is useless, because that 0.0001ms can eat 80% of time and FPS on slow machine can be dropped from 60 to 10. That 8% for 1024x768 is really big difference and it will be very hard to find an another place for such big improvement.

Wrong!

Percentage only has meaning with a usable frame of reference. In your most extreme example you see a 24% difference. The problem is that it's 24% of nothing which makes the entire comparison worthless.

To make an informed decision you need an absolute value on which you can base your decision.

And even in your other examples, it's still 8% of less than critical. To get some true comparisons you will have to take a situation that's much closer to the actual refresh times of a monitor. On most systems it makes no difference if you got 160 or 180 fps (unless you are an FPS whore of course :P) but it would matter if you had 70 vs. 80 fps on a 85 Hz monitor.

ZDoom has completely dropped statusbar caching, btw. On Windows it uses hardware acceleration by default and for the fallback it was decided by actual Linux users that the performance gain was not worth the complications.

[entryway]

Graf Zahl said:

Percentage only has meaning with a usable frame of reference. In your most extreme example you see a 24% difference. The problem is that it's 24% of nothing which makes the entire comparison worthless

Try these two EXEs on Pentium1 or 486x. 24% will be ~24% anywhere. I have fast computer and that 24% does not matter for me, because I do not need more than 100 fps, but it can makes sense for slow computers and devices.

In your terms, any optimization of prboom will be absolutely useless, because there are no levels with fps < 100 on my Core2 and with my prboom.cfg.

Graf Zahl said:

On most systems it makes no difference if you got 160 or 180 fps (unless you are an FPS whore of course :P) but it would matter if you had 70 vs. 80 fps on a 85 Hz

You are right. That's because only percentage does matter. Try it at 2500x1900 on slower computer and you will get that 75 to 80 improvement easily.

[Graf Zahl]

That wasn't what I said. All I said that percentage of FPS is not a good measurement because it's without reference that can be applied in meaningful ways.

Time spent combined with a CPU type, on the other hand, is something that tells some usable facts.

In this case it tells us that on a relatively fast system drawing the status bar takes between 0.2 and 0.5 ms. Which in turn tells us that on slower systems the time spent on it may be indeed too much to warrant simplifying the code.

Your percentage values, on the other hand, only told me that on levels that don't do anything the percentual difference is larger than on more complex ones. I had to get the ms values out of your comparisons myself by taking out my pocket calculator just to have something usable.

What all this number crunching does not tell us though is that Doom's original status bar code is a hideously ugly mess. It may make more sense to redo it while preserving the caching. ZDoom's old status bar code, for example, did cache but it worked completely differently and as a consequence was much easier to read.

(Also, if you really are interested in performance boosting I'll reiterate what I said some time ago: P_CheckSight is a great place for optimization because it's using such an inefficient algorithm.)