Ren'Py stops responding to input when rendering takes too long

[Spiky Caterpillar]

If a displayable takes too long to render, Ren'Py can wind up ignoring user input in favor of repeatedly redrawing the screen. The attached script.rpy exercises the bug - shift-R will not reload the script on 6.9.3c, and it can't be quit normally. I've also seen the same effect with complex custom displayables on slow machines (and with poorly written complex custom displayables on fast machines.) IMO, interact_core() should process the entire event queue after each frame instead of just the first event. A somewhat ugly patch to do that is also attached; it seems to work with the sample program and with my latest project, but I haven't tested it thoroughly. The most likely thing I can think of that it might break on is displayables that trigger a redraw from within their render() method.

[Spiky Caterpillar (spikycaterpillar)]

Bug exerciser.

[Spiky Caterpillar (spikycaterpillar)]

Updated patch to get the mouse position from the event instead of using the current mouse position. This way, mouseup events will be handled as a mouseup wherever the actual mouseup occurred instead of a mouseup wherever the mouse is now, falling back to the actual mouse position if there is no position in the event.

As before, I've been using this patch for approximately four minutes, so there's still risk of it breaking unexpected things.

[Tom Rothamel (renpytom)]

I went in a different direction, but the fix will be in Ren'Py 6.10.0.