feat(core): drop support for after-step-hook

[matejcik]

Chipmakers hate her!

Local granny discovers One Weird Trick for saving up to 50 % clock cycles

(less on actual hardware)

so it turns out that in loop.py::run() the hottest of our hot paths, there's this code:

if after_step_hook:
   after_step_hook()

what's after_step_hook, you ask?
well, on Trezor T, it's None. so that's one useless code branch
(and no, this isn't optimized out, we're in Python here)

In emulator, and on T2B1, after_step_hook = display.refresh()
I don't exactly recall why this was there. My suspicion is that with the previous UI toolkit, we relied on immediate mode painting on the TT but it didn't work on the emulator (nor when we later added TS3 that paints into an internal buffer even on real hardware).

Then UI2 came along and we're sticking explicit ui.refresh() calls liberally on all painting paths, presumably because the implicit refresh was failing in some weird cases? Maybe Rust is drawing something without hitting the loop? Maybe the screenshotting thing had a problem? I don't know, hence why this is just a draft for now.

...annnnyway. By completely random chance I was profiling the emulator and noticed that display_refresh() gets called billions of times.

Removing the whole after_step_hook mechanism doesn't seem to have any adverse effects in my (limited) testing so far, and it speeds up device-tests in frozen build by a whooping 50 % (that's in headless mode so no actual screen drawing, mind you. but under the hood the texture updates were happening anyway).

[mmilata]

I don't remember why refresh was added to the paint path, possibly something to do with rust homescreen d00e87e? Either way if this works on T2B1 hw and speeds up tests then let's merge it.

[matejcik]

Found another extremely subtle bug that could cause test freeze in some racey cases. If we're extra lucky, it will fix test freezing on hardware.
(loop.close() was incorrectly leaving entries in the _paused queue, and it turns out io.poll() would pick up all events for which an entry exists, even if there are no tasks waiting on that entry. This would cause a race between ... something closing out the workflow task, presumably? I haven't dug deep enough to see why the paused queue becomes empty, but it does, and loop.close() is the only place that explicitly removes things from the paused queue (the main loop in run() will just pop the whole thing out)
...anyway. There's a race between something removing an item paused on USB read, and the handle_session read step coming in to insert itself back to that slot. So an USB packet or two can get silently dropped.)

e36ec20, @mmilata please check my logic

Also added a minor change to debuglink that causes the homescreen-at-start-of-test to always be recorded.

[matejcik]

...ahh, right, no, the code is wrong, i'm modifying the thing i'm iterating over.

[mmilata]

That's nasty. My intuition for loop.py code is bad but what you say is true and the fix seems correct.

[github-actions]

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T2B1 Safe 3	3280	test(screens) main(screens)	2724
T3T1	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

[matejcik]

...of course this kills TR click tests with a thing that I'm pretty sure I dealt with in global layout.

[matejcik]

...of course this kills TR click tests with a thing that I'm pretty sure I dealt with in global layout.

turns out it's its own thing. a legitimate bug in TR button code and/or timer handling, that just happened to have been hidden by the loop being a tiny bit slower

[matejcik]

superseded by #3702