Ok, so it seems this is not a regression in the API. However on windows it is a performance regression, as the directx backend isn't the default anymore, and that provided much faster hardware accelerated blits for things like color keys.
So, no more help needed right away thank you :) But I agree with Ian and Gumm that it's not a nice understandable API. And I think Gumm will propose an enhancement sometime later. cheers, On Saturday, July 14, 2018, René Dudfield <ren...@gmail.com> wrote: > Thanks. So, I guess it's worth fixing before the release. Yes, those are > the same bug reports on the mailing list, and the old bitbucket. But I > guess the change was probably made some years before those reports. > > We still need to find when the issue was introduced, and have a test case > for it. > > > > > On Sat, Jul 14, 2018 at 3:54 PM, Ian Mallett <i...@geometrian.com> wrote: > >> Hi, >> >> As to finding the commit, can't one find the place where the behavior is >> implemented, and then check the logs for that line/file to see which commit >> introduced it? A trivial search of my email for "SRCALPHA" produces the >> thread "trouble w/ SRCALPHA in 1.9.2-cp27 >> <http://archives.seul.org/pygame/users/Nov-2017/msg00038.html>", where >> this same issue was raised (ref. issue #340 >> <https://bitbucket.org/pygame/pygame/issues/340/surfaceconvert-does-not-remove-the> >> on Bitbucket, by presumably-same user even). At the time no one stepped >> forward to address it significantly. >> >> As to whether the behavior is good, I contend it is bad. SRCALPHA and >> per-surface alpha are *very* different, and confusing them is a classic >> newbie mistake. Now, I don't use the flags myself, and even presuming >> pygame uses them internally, I use per-surface alpha rarely at-most, so it >> doesn't really affect me. But it is semantically incorrect. >> >> Ian >> > >
