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 <mikhail...@gmail.com> wrote: > On 18 March 2015 at 23:05, Greg Ewing <greg.ew...@canterbury.ac.nz> 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 >
