Closed gurgalex closed 5 years ago
Hmmm. Might be due to the thread sleep basically telling the system to give another process a chance. Without the thread sleep though, it will run at 100% CPU. I wonder if there is a way to flush the event queue on each iteration. Otherwise, perhaps having thread sleep of 10ms or so might prevent this.
Well, on Linux (Arch) it is already running at 100% of one core with a 0ms sleep time.
Setting it to (1000/60) ms reduced the cpu usage to ~1%.
Inputs still get queued up with this change, it happens more with rendering very large images (1920x6000).
So clearing pending events may work (if possible)
Ah, ok. Giving it even a zero ms sleep time was enough to prevent 100% cpu usage on mac, but good to know that it's still doing that on linux. That definitely needs fixed. 1000/60ms sounds like a reasonable default.
As for clearing the queue, I can't find anything just now. I'll look later. There's a wait version of the iterator that might change the behaviour. I won't get a chance to look until tonight, but feel free to play around.
Right now I see this as neither actionable nor a significant issue. So I'm closing it for now. We can re-open later if it becomes a problem.
Hmm, it's still an issue that becomes more apparent if lots of large (multi-screen) images are being cycled through.
Could we have labels like (P-low) for low priority issues. That way they aren't forgotten about.
Holding down say
j
to move to next image rapidly upon release will scroll to next couple images.Possibly because say 20 images were rendering in 1 second, but 23 j presses were picked up?
So after releasing the key, there are still 3 pending j presses left to handle, hence 3 more images rendered.