Jason Tackaberry wrote: > On Fri, 2005-06-10 at 21:43 -0400, Jason Tackaberry wrote: >> 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? > > /me breaks cvs head.
I will take a look at it.
> Ok, based on a (albeit brief) discussion with dischi on IRC, I stripped
> out all the pygame code from Imlib2 and created a separate module called
> mevas.displays.pygame_mevas. PygameCanvas imports this module and uses
> the image_to_surface() function to do what Imlib2.Image.to_sdl_surface()
> was doing.
OK
> I tested that this works with mevas, but I suspect that I may have
> broken Freevo cvs because now mevas can't be imported directly from the
> source tree. I'm not sure if freevo relied on this before, or if it
> assumed mevas was already installed in the system path. If this is
> needed, I'll see if I can rig something so that the extension module
> gets copied to the displays directory when setup.py build is run. Maybe
> somebody knows distutils better than I do and knows how to do this
> properly? Because I have no clue. :)
I also have no clue. I always do the copy stuff. It is in pyimlib2 and
mmpython and I don't know a good way to do this right. But Freevo
should work without mevas installed into the system.
>> 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).
>
> I'm trying to figure out why I thought this was a problem, because right
> now it seems pretty obvious how to do it. I hate that, because I don't
> know if I was just suffering from a chronic brain fart, or if there was
> some deeper issue I've now suddenly forgotten. :) At any rate, the
> current API for this (get_raw_data/free_raw_data) needs some serious
> fixing. I'll probably do that next.
You did something with a buffer object. I changed it to the current
stuff. I tried to check all possible memory leaks and failures and may
opinion was that it works. But it seems like this is wrong. So it was
me, not you who did this. Please add some docs into the code how it
works and why you are doing it this way.
>> (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.)
>
> This is eminent. If you need YV12 speak now.
No
Dischi
--
panic("kmem_cache_init(): Offsets are wrong - I've been messed with!");
2.2.16 /usr/src/linux/mm/slab.c
pgpHmrOz6JYKe.pgp
Description: PGP signature
