Screen tearing

Somewhere between 1.2.0 and current main a lot of screen tearing has been introduced. I have checked that switching ST3M_GFX_NBUFFERS back to 2 does not fix it, so it must come from somewhere else.

An easy way to see it is to use the older version of "Harmonic" app, which fades the scope from white to black after each petal press. On 1.2.0, the fading animation is pretty smooth; on current main it gets easily distorted by horizontal lines.

(for what it's worth, on 1.2.0 it isn't perfect either - there's some occasional small amount of distortion that somewhat resembles screen tearing, although does not exactly look like it... could even be an artifact of the display itself. It's very prominent on current main though, so the difference is quite obvious)

Could you provide a small test case, or even the relevant code reproducing it dug out of git history to make it easily reproducible?

https://git.flow3r.garden/flow3r/flow3r-firmware/-/blob/v1.2.0/python_payload/apps/demo_harmonic/init.py

odd, I could not launch this with mpremote but it works on device. I am not fully familiar with the graphics stack yet. But there is indeed tearing, higher frame rate could be the cause of it being more prominent. The faster we render the more obvious it will become. As far as I know there is no vsync implemented|provided in the driver we are using.

I don't think it's a framerate thing. It's still visible when framerate drops with the new firmware. I suspect it's about the screen rotation changes, but haven't verified it yet.

It's actually somewhat more prominent with low FPS, as it looks obviously like tearing and not like a gradient anymore ;)

Indeed, reverting !227 (merged) makes it behave like in 1.2.0 again.

Given how tightly the vertical gradient bands resulting from the fade are spaced, putting a limit at how many framebuffers we try to upload might be a good idea, reducing the count of tears to 1 instead of lots.

mentioned in issue #101 (closed)

I wonder if !266 (merged) helps with this?

Among other things it removes st3m_gfx_crtc_task and merges it to st3m_gfx_rast_task and the fact that these were two separate tasks that could run in different cores at the same time while only sharing one in-memory buffer always felt like it would defeat the double buffering the display gives us for free

edit: disclaimer i don't really know this topic

Nevermind this was also asked here and the answer is no #101 (comment 12643)

added bug label