Heh, hostility is fun, right? I am not a C programmer, please pay attention. I have used colorkey, but that is not a straightforward way to increase speed. Since it involves a check on each pixel, some images may not benefit (and in fact will lower performance) if there isn't much transparency. Wheras a 'blit' on matched pixel format surfaces can be a simple memory copy operation, depending on the platform.
To illustrate a use case for an "unsafe blit": In tile map drawing, you will be doing potentially hundreds of blit operations. Since tile placement is very straightforward, you can be sure there will be no out-of-bounds blitting. You can enforce pixel formats when the surfaces are loaded. So, format checks are only needed when surfaces are loaded, not every time there is a blit operation. (Also, this is just one potential scenario, please don't elaborate on different way to render a tile-based map, just stick to the topic: "unsafe/fast blit") As is, the 'blit' operation removes several chances for error, especially for people who don't care to convert surfaces or set clipping regions, but it does so at a performance cost. It could be as simple as making the following function available to pygame, perhaps in some inconspicuous place, not a part of the surface class...in order to discourage abuse: https://wiki.libsdl.org/SDL_LowerBlit On Sun, Mar 13, 2016 at 3:10 PM, mspaintmaes...@gmail.com < mspaintmaes...@gmail.com> wrote: > I don't think this is a trolling scheme. Since OP said this would > "obviously cause graphical errors" if the input was bad, I don't think they > are going to be surprised and then file a bug. Also, non-C programmers are > programmers, too :P > > Since a hypothetical "fast_blit" (or possibly "unsafe_blit") requires the > user to make sure all the formats are the same, bounds are checked, etc > ANYWAY, the overhead of normal blit's rule-enforcement would basically be a > no-op, ergo normal blit is the same as fast_blit if used with the proper > inputs. Are you familiar with color_key? If you're using blits with > per-pixel alpha and you don't need translucency, switching to color-key > usually gives a noticeable performance boost such that any rendering code > slowness is dwarfed by non-rendering code. > > On Sun, Mar 13, 2016 at 12:18 PM, Martti Kühne <mysat...@gmail.com> wrote: > >> So you're not a programmer but you want a fast method that potentially >> delivers surprising results because you don't want to care about the >> pixel format? >> >> I'm starting to suspect an elaborate trolling scheme here. Are you >> planning to file a bug about the surprising results then, already? >> >> cheers! >> mar77i >> > >
