--fade_time setting ignored by PictureFrame2020.py?

[jeffalperin]

The --fade_time parameter seems to be ignored, whether set in the config file, on the command line when invoking PictureFrame2020.py or via mqtt. The transition between images seems to last for about 10 seconds when --fps=20.0 (and about 15 seconds when --fps=30.0).

I added a little logging code to PictureFrame2020.py at the top of the while DISPLAY.loop_running() loop to check the value of fade_time, and the logging shows that the expected value each time through, but the transition time doesn't reflect that value. I've used values of 2.0, 4.0, and 8.0. I'm using 4k/16:9 images (3840 x 2160) on a rPi 4 (8gb).

--Jeff

[paddywwoof]

I suppose the first thing to do is check what FPS you're actually getting. That will be useful when checking out the 'jerkiness' issue too. You could do that by doing something like

num_run_through = 0
f_num = 0 # <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
f_tm = time.time() #<<<<<<<<<<<<<<<<<<<<<
while DISPLAY.loop_running():
  tm = time.time()
  if f_num >= 100: #<<<<<<<<<<<<<<<<<<<<<
    print("FPS={:.1f}".format(f_num / (tm - f_tm)))
    f_num = 0
    f_tm = tm
  f_num += 1 #<<<<<<<<<<<<<<<<<<<<<<<<<<<
  if (tm > nexttm and not paused) or (tm - nexttm) >= 86400.0: # this must run first iteration of loop

If the achieved FPS is less than the target FPS then I would expect the fade_time to be longer than you had set, but I would expect it to be proportional - in the same way that it seems to be proportional to the target FPS in your example. i.e if you set:
--fade_time=2.0 --fps=20.0 and get 10 seconds in practice, I would expect --fade_time=4.0 --fps=30.0 to give an actual fade of 30 seconds.

This is because the script works out the delta_alpha for each frame as

    delta_alpha = 1.0 / (config.FPS * fade_time)

or, for the first example 0.025 - basically 40 frames. But if the FPS achieved is only 4FPS this will take 10s to change from 0 to 1. However if you set config.FPS to 30 and fade_time to 4 it will take 120 frames (delta_alpha is 0.008333) or 30s at the achievable 4FPS. You could verify this for me just to make sure this is what's happening.

If you want to get a reliable transition time of 2s and display can only run at 4FPS then you need to have delta_alpha of 0.125 so you should --fade_time=2.0 --fps=4.0. However those are quite big jumps in alpha and, at 4FPS, it will look pretty steppy. Really the best way to cover up for the fact that the screen is running at low FPS you should aim for very long transitions so that the change in alpha is imperceptible.

[jeffalperin]

Here are the FPS results I found with 3840 x 2160 images:

with --fps = 20:

• actual FPS was about 6 @ 4k (native) resolution
• actual FPS was about 20 @ 1080p resolution

with --fps = 30

• actual FPS was about 6 @ 4k (native) resolution
• actual FPS was about 23 @ 1080p resolution

So, this would seem to explain the observed "jerkiness" and timing issues, but why is the performance so different with the display in 4k mode? By the way, the display is 4k @ 30Hz; I've had difficulty enabling 4k @ 60Hz; would that make a difference? Is there anything to do to "speed up" the actual FPS in 4k mode?

[jeffalperin]

I just tried measuring FPS at 4k resolution with images which were down-sized to 1920 x 1080. Results were about the same as with the 3840 x 2160 images, so image size seems to have no effect on observed FPS.

[paddywwoof]

Sorry, been out today. The issue is really that the GL driver on the RPi (or possibly the GPU itself) struggles to get through the fragments (approximately pixels) The old broadcom driver didn't seem to be quite as slow but there are nearly four times as many pixels to process hence the 23 to 6 speed difference.

As the fragment shader is the bottleneck nothing else will make any difference. The only option is to make shader faster, I will have a look into that but it's fairly simple so I doubt I can get much.

The refresh rate will probably effect video playback but that operates in quite a different way so not really relevant.

Will let you know what I find.

[jeffalperin]

I had another thought. Have you considered computing delta_alpha using actual (i.e. computed) FPS instead of the --fps specified in the config? Obviously, you'd have to use the config.fps number for at least the first image, but if you used some sort of trailing-average actual FPS, then the --fade_time setting would be more intuitive (and accurate).

--Jeff

[paddywwoof]

I actually thought about using the time, that's what happens with the fading text, but (without actually testing it) I thought it might be more visible if there was uneven FPS due to background tasks. I might try it out and see what it looks like. Is the fading very steppy at 6FPS?

[jeffalperin]

I'm using a --fade_time=6 with --fps=20 and --time_delay=30. With those parameters, it's not too bad. The text fading itself is a little steppy, though.