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 >
