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 <i...@geometrian.com> wrote: > Hi, > > 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 <https://bitbucket.org/pyglet/pyglet/wiki/Home>. > 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. > > Ian >
