[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] pygame with SDL2 proposal

Thanks Ian for the clear post! I think this is the sort of thing I was trying to get at, but I don't know as much about it.

On 20 March 2017 at 17:42, Ian Mallett <ian@xxxxxxxxxxxxxx> wrote:

As sort of a side-note, since performance has come up . . .

Per-pixel drawing operations, if they must be individually managed by the CPU, will always be much faster to do on the CPU. This means things like Surface.set_at(...) and likely draw.circle(...) as well as potentially things like draw.rect(...) and draw.line(...). And it means everything, if there are a lot of calls. The GPU is obviously faster at graphics operations in-general, but it's still a thorough loss if you have to send the commands over the PCIe in the first place: if not in processing time, then in latency. As a matter of fact, this is true for most things people try to use GPUs for, and mitigating it is why e.g. Vulkan has to be so complex.

What does this have to do with anything?

Well, it's a philosophical question of what we want pygame to be:

1: Hardware-accelerated pygame-API-compatible library. (Basically won't work for reasons above.)
2: Hardware-accelerated pygame-API-incompatible library. (Fine, but AFAIK this already exists. There are probably other projects too.)
3: Software pygame-API-compatible library. (We have this now, and any movement to SDL2 should be considered in light of what features it changes (i.e. many misc. improvements, but worse (?) blitting).)
4: Software pygame-API-incompatible library. (Works best, IMO, with any plan to support SDL2.)

Python is a slow language, and if you're using it, you're implicitly saying usability is more important right now. This includes graphics, and pygame is currently occupying that niche: highly usable, low-level, slow(ish; still pretty fast) graphics. If we want hardware acceleration (options 1, 2) then we're moving outside that niche. Ditto, to a lesser extent, breaking compatibility to add more-modern features (option 4). So basically, what it comes down to is whether we like our niche, whether moving to/incorporating SDL2 is focusing on a real problem, if so whether moving to SDL2 affects our feature set in ways we do like, and if so whether this affects our niche in ways we don't like.