Current rendering and game logic

[ebenupton]

As I understand it, game logic and SDL rendering operations run synchronously. When running on devices with several cores but limited single-thread performance, it would be helpful to hive off rendering into a separate thread, allowing it to proceed asynchronously on a second core. We have examples of games on Raspberry Pi which would run at 30fps in this mode but which are currently stranded (even after a fair bit of optimisation on the SDL side) nearer 20fps.

I'm sure we could knock something up, but if this is feasible it might be better if it were done by someone closer to the project. We would consider providing a bounty to get this done.

[lordmauve]

I have been thinking about this for a while. While there are speed-ups there are problems for correctness. If a surface queued for drawing is updated in another thread, the wrong contents will be drawn when the surface is eventually drawn.

We could work around this by copying the surface when moving it to the draw queue - but this is extremely expensive when it is so likely that the surface will not be updated. Still, this may offer some speed-up.

This cost could be mitigated altogether, however, if we could have copy-on-write clones of surfaces. In the typical case, where surfaces are not written back to, this would simply create a temporary object pointing to the same underlying surface data. But if the surface was written back to, it would be copied by whatever thread wanted to write to it.

For this to be fully compatible with other Pygame code this would need to be in Pygame itself, however. I got as far as suggesting this on the Pygame mailing list, but there wasn't much interest:

http://pygame-users.25799.x6.nabble.com/Cheap-COW-clones-for-surfaces-td3353.html

It would be interesting to try to write a patch to Pygame for this but I am unlikely to find the time. And perhaps the time would be better spent porting Pygame Zero to an OpenGL rendering backend (and dropping Pygame).

[ebenupton]

Interesting. I hadn't considered that retaining the ability to do classic Pygame operations alongside Pygame Zero ones was a design goal, but now I think about it I've written at least one game that relies on setting the clip rectangle on the screen surface. Of course this is an example which wouldn't even be helped by COW surfaces.

Perhaps allow the user to declare that they don't need legacy functionality by setting a global? Pretty filthy though.

[lordmauve]

Perhaps the time would be better spent porting Pygame Zero to an OpenGL rendering backend

This is the direction I've pursued, with https://github.com/lordmauve/wasabi2d

I think PGZero 2.0 will be likely be on top of wasabi2d.

[ebenupton]

Very cool. You would have to do this to me on the day our Pygame Zero book goes to press of course :)

[lordmauve]

Pygame Zero isn't going anywhere. In fact, by at least scoping out what I'd like a pro version of Pygame Zero to look like, I have a better idea on how Pygame Zero should evolve.

[fillwithjoy1]

You could run 2+1 threads - one for the draw() function and the update() function and an extra thread for other aforementioned functions that are hidden in the code. Just an idea