Re: [pygame] Feature discussion, proposals
The thing is, hardware makers tend to strive to optimize the most used paths. I don't have any internal knowledge of modern hardware, but following this logic, 32 bit blitting may actually be the most optimized as it is the most common method of rendering. By using convert(), you let the hardware decide which path it thinks is the most optimized. On Wed, Mar 18, 2015 at 4:13 PM, Mikhail V wrote: > On 18 March 2015 at 23:05, Greg Ewing wrote: > > Mikhail V wrote: > >> > >> 1. It turns out that 32 bit surfaces is an overkill in most cases. Good > >> that there is 8 bit mode. > > > > > > What evidence do you have of that? Have you done any > > benchmarking? > > Evidence of what? I ment, almost all the time I don't need so much > bits per pixel, unless I want to see realistic photography. Many > programs I wrote exploit index processing only. rgb encoded formats > just don't apply for most algorithmically created image and > processing, regardless of performance or 'realism'. > And less bpp should be faster memory to gpu memory transfer, I > imagine? If my source is say 4 bits per pixel then converting it every > cycle to rgb and transfering it per 24 bpp stream format is not the > best practice. > > Mikhail >
Re: [pygame] Feature discussion, proposals
On 18 March 2015 at 23:05, Greg Ewing wrote: > Mikhail V wrote: >> >> 1. It turns out that 32 bit surfaces is an overkill in most cases. Good >> that there is 8 bit mode. > > > What evidence do you have of that? Have you done any > benchmarking? Evidence of what? I ment, almost all the time I don't need so much bits per pixel, unless I want to see realistic photography. Many programs I wrote exploit index processing only. rgb encoded formats just don't apply for most algorithmically created image and processing, regardless of performance or 'realism'. And less bpp should be faster memory to gpu memory transfer, I imagine? If my source is say 4 bits per pixel then converting it every cycle to rgb and transfering it per 24 bpp stream format is not the best practice. Mikhail
Re: [pygame] Feature discussion, proposals
Mikhail V wrote: 1. It turns out that 32 bit surfaces is an overkill in most cases. Good that there is 8 bit mode. What evidence do you have of that? Have you done any benchmarking? - how does the indexed image is generally rendered? Is it like: it sends index array to video card and the card makes substitution? That would depend entirely on your system, and I would expect huge variations from one system to another. Even if using indexed images is a performance optimisation on *your* system, it's likely to be a pessimisation on someone else's. Personally I would forget about optimisation and only use indexed surfaces if it simplified my program logic. For performance, I trust convert() and convert_alpha() to know more about the system it's running on than I do. -- Greg
[pygame] Feature discussion, proposals
Hello all pygame people, I am using pygame about a year now, and was thinking about, what useful core features would be nice to have or improve. So for now I have pair of thoughts, just looking forward for informal discussion about your ideas too. To mention: I am not the pygame library developer, so don't actually know how the things work behind the lib. So at the moment there are two things which I experience and think about. 1. It turns out that 32 bit surfaces is an overkill in most cases. Good that there is 8 bit mode. But I ask myself: - how does the indexed image is generally rendered? Is it like: it sends index array to video card and the card makes substitution? if yes this could be a great simplification for my program logic and minimize redundant conversion on cpu. I could make all the calculation in integer arrays and just pass the array to render in my palette. Or am I only dreaming? But sure enough modern cards can do the substituton effectively. - how is about supporting 16 bit indexed rendering? 8 bit is good but 16 bit would be also not bad. Numpy also supports int16 type. - when something is not possible due to SDL possibilities, could the latter be changed somehow? 2. Using bitmasks for rendering. This was discussed and asked several times on stackoverflow, how to blit in a mask. Fast option is colorkey. But AFAIK it is still not possible to blit inside custom defined bit mask (simple boolean array), so would be a nice feature too. Colorkey is simple but not so flexible and you must always check if colorkey value does not occur in the image. Cheers Mikhail
