Closed piegamesde closed 3 years ago
idanarye
commented
3 years ago Mmm... in the #7 discussion I was worried about signals that fire too much and slow things down - so I guess these continues events are an example? We could use them a benchmark, to see if I'm prematurely optimizing or not. If I crank the Tokio runtime inside each such event and it's still fast, then moving to that style would solve this problem as well (because the queues will clear before the next signal can fire)
piegamesde
commented
3 years ago The annoying thing is that this has little to do with the performance of WoAB and the event handler for the resize signal. The drawing code is completely independent from this except for the fact that resizing triggers a redraw (this would even happen if I hadn't any resize handler). The triggered redraws slow down the whole main loop. Because of the prioritization, the GTK events are processed before the Actix ones. Every GTK event gets pushed onto the signals stream of that actor. And because GTK is busy doing redraws and new resize events keep coming in, they quickly pile up in the queue and overflow it.
If you crank the Tokio runtime inside the callback, this effectively prioritizes WoAB, and the events will pile up within GTK instead of Actix. I think GTK is "solving" this issue by having an unbounded queue :) As you said, this will probably resolve the issue.
Btw a quick work-around would be to simply use an unbounded channel for the event streams ;-)
It's not hard to reproduce. Simply hook up a callback into the
configure-eventsignal and then let it trigger a few non-trivial redraws. I think the message pipe size is 16, which is easy to overflow when dragging the window and things are a bit laggy.Same then also counts for other continuous gestures like mouse input.