screen q size / indicator

[catfact]

like an idiot, i entirely forgot i had added a visual "warning" for when the screen event queue is filled.

in a way it's good that we know some scripts are hitting the Q capacity. but it makes me wonder if the Q shouldn't be bigger / grow as needed. (we don't say that you can't queue up thousands of drawing requests at once.)

[tlubke]

This conversation on lines gave me an idea.

Apologies if I’m misunderstanding the actual issue, but: if the queue is long enough would it make sense to skip queue entries rather than flush the queue entirely? e.g., every other or every 4th entry or whatever. Basically rather than having the script author reduce their framerate, reduce it for them at the system level 🤔

no, it’s not a queue of frames

The idea is pretty simple -- anytime the queue needs to skip an entry, we can clear everything up until the next SCREEN_UPDATE event. Though it's not a queue of frames exactly, it is a queue of events that make up frames.

That probably wouldn't fix the case where there are enough drawing requests to fill up the queue before a screen update event. I think your idea for a dynamically resizing queue makes a lot of sense for that reason.

[xmacex]

For documentation, the flashes look like this; a single-frame half-screen yellow rectangle.

[catfact]

i'm on coding hiatus for the month but will get back to this (and other small norns issues) in the new year. sorry for the delay. if anyone wants to adjust the white square appearance (for visual sensitivity), that is here:
https://github.com/monome/norns/blob/main/matron/src/screen_events.c#L596-L608

(idk why i put several updates in a row. this has the vibe of something done in the deep frantic midst of a long session.)

and the q size is here:
https://github.com/monome/norns/blob/main/matron/src/screen_events.c#L11

[dndrks]

just for testing any future changes, acrostic has a lot of queue-filling redraws and is a reliable test candidate