I'm not sure what the current state of things are, but at some point in the not-so-distant future I'd like to do a release of pyimlib2. There are some things that don't quite belong there. The shmem code is one example, which I've recently removed. The other thing I'm not happy about is the pygame stuff. Is there any plan in Freevo to remove dependency on this? If not, is there some other way we can accomplish this without having this kludge in pyimlib2? Does pygame allow memcpying a buffer (which Image.get_raw_data() will return) to a surface?
Speaking of get_raw_data(), there's been some changes to this code since
I last looked at it, and it's broken. It looks to me that if we do:
buf1 = img.get_raw_data("RGBA")
buf2 = img.get_raw_data("YV12A")
Then buf2 will actually have the same data as buf1 (i.e RGBA data
instead of YV12A). I remember having some code which wrapped the buffer
object returned by get_raw_data() with a class that called inside
_Imlib2 to free the memory allocated when its destructor gets called.
Yes, it was very kludgey, but it worked. I'll see about a more elegant
solution to this problem, but correctness is more important than
elegance (not that the current code is particularly elegant).
(In all honesty, the whole YV12/YV12A thing was necessary for bmovl2,
but it's also a kludge. I don't need it anymore for my new work, since
vf_osd reads BGRA directly. I'm happy to remove this stuff from
pyimlib2 as well, and have get_raw_bytes() just convert between (RGB|
BGR)(24|32) colorspaces.)
Also, I think the existence of the fdo thumbnail code in pyimlib2 is a
bit dubious. But if we define pyimlib2's scope as "an Python image
library that uses Imlib2" instead of "an Imlib2 wrapper for Python" then
we have a bit more freedom about what we can do. I'm personally happy
to accept the former definition and leave the fdo thumbnail code there.
I think the pygame stuff might be stretching it though. :)
Cheers,
Jason.
signature.asc
Description: This is a digitally signed message part
