2 cents from a Windows developer.
I checked out Freevo 2.0 from CVS a few weeks ago, and did some work on
getting it running in Windows. I got the main menu working with keyboard
input, though it didn't do much more than that.
Related to pygame and pyimlib2, I would request:
- pygame not leave the Freevo 2 codebase, of that is what may be
suggested below (and I am not sure that it is).
- pyimlib2 not be required for Freevo 2. pyimlib2 wraps imlib2, which is
not available on Windows.
I was able to use pygame for all implementation - after filling in quite
a few methods - and had to remove some dependencies on pyimlib2, which
is not available on Windows.
There were other issues, which I will summarize in a follow-up email.
Thanks,
Tyler
Jason Tackaberry wrote:
>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.
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 6/11/2005
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Freevo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
