On Mon, 2005-04-18 at 17:40 +0200, Dirk Meyer wrote: > The idea of using jpg files isn't mine. I stole it from enlightenment. > So they would reuse our thumbnails and maybe the freedesktop.org > change the spec some day.
Ok, that's a start. Yes, with real applications (well, in E's case, for certain definitions of "real") using this approach, there's a better chance for the spec to get amended. > Yes, it should be something else, but that tiny little epeg and png > code doesn't hurt :) As soon as I added the shmem and colorspace conversion code to pyimlib2, I knew right away it would suffer from creature feep. But I think if we change pyimlib2's scope from "Imlib2 wrapper" to "image library (that uses Imlib2)" then things become ok. :) > Nothing against tabs, but setting tabs to 4, no that's bad. Your > indention style is still there. Yes, ok, I shouldn't have had "# vim: ts=4" in the file. That was very selfish of me. :) > CVS should be stable enough for some testing. I have it at daily use > and it feels ok. I shall update then. > WOW, I want that, too. :) It looks like a merge between by new mediadb > and the vfs with some database features. How fast is it? It written ground up with performance and (more importantly) responsiveness in mind. It's very fast. I do testing on directories with 10000 files to make sure things scale properly. With inotify, callbacks connected to directory monitors where the vfs directory is an actual filesystem directory, the monitors are signaled immediately. So, a file gets added, and the monitors are signaled a "added" event. The UI can immediately add the item to the list. When the file stops changing (say a user is copying an image to the directory), the image gets indexed by the vfs (thumbnail created, metadata fetched and put into a database [sqlite backend]) and the monitors are signaled a "changed" event to update the display. Where the vfs directory is not an actual filesystem directory but a database query, the delay is a bit more since the current implementation does polling (i.e. it requeries the database every couple of seconds). So the file gets indexed and added to the database immediately as in the above filesystem case, but the monitors for the vfsdir query won't get alerted until the database gets polled again. However I've some logic to add to eliminate polling and instead of the thing requery only when there's an update to the database, so the delay will be pretty quick. Less than a second. For inotify I just rolled my own code to talk to /dev/inotify rather than using gamin (which would have incurred yet another dependency). The code for that is trivial. Less than 100 lines. Maybe you can use it in freevo. But last night I came up with some more ideas and will probably wind up rearchitecting the whole vfs stuff yet again. I want to put file indexing, directory monitoring and device (removable media) monitoring in a separate process since these things tend to block the most. But I'm not sure if these functions should be in a separate process, talking to the main process via ipc, or rather in a separate thread. I need to do some experimentation with that. But that's the reason I want to add the begin/end threads stuff in pyimlib2. I tend to shy away from threads too, though. Things are extremely difficult to get right. > I guess we will stick to mbus but maybe make the iterface more look > like that. I thought of mbus. But adding another dependency for something relatively easy to do from scratch made me weary. My IPC code is only 450 lines and it's fairly straight forward in design, mostly because it relies on pickling and delegation to do all the magic. Having done some work with CORBA in the past (I did my undergrad thesis on CORBA in Python, in fact), I just wanted something that's no-bullshit and doesn't get in the way. In either client or server case, there's just 2 lines of setup before you can start using the object as if it's a local object. That still really amazes me. I love Python. :) > NOOOOO, mevas is working so good and you are telling me that you are > doing an eval port for python and it is even better? You know I can't > resist playing with that :) I knew you'd feel that way. :) When I came up with the idea to use evas, and the realization that it would probably work, I thought, "But what about all the work I put into mevas, and Freevo is using it, and I'd be abandoning it!" But I can't let those things sway my decision to pick the right solution to the problem. :) Evas isn't without its problem though. There are some limitations that I'm going to have to address somehow. For example there's no way to add an alpha mask to an Evas object, so we can't do the fade-out Text effect for long lines. That's a big one, clearly. (I talked to someone in #edevelop and he said he might add that at some point, but was busy. But it does seem architecturally possible within evas, anyway.) Also Evas didn't support rendering BGR32 to a memory buffer. (Does BGR24, but BGR32 was a FIXME item.) Luckily that was just a few lines to add, and I hacked that in myself. But it doesn't support it natively, which is required for vf_osd. (I suppose that's not such a big deal, I imagine raster takes patches :)). But the _main_ benefit of evas in MeBox is simply opengl. You can do scaling and alpha blending (and all that good stuff) of a movie without any additional CPU overhead. It's really slick on my GF4MX. Of course, not all systems will have GL support, so I've been testing the regular X11 case heavily. Doing a 400x300, say, video evas object is very feasible without GL. But you wouldn't want to do that full screen. And even if CPU wasn't an issue, you wouldn't want to do that anyway, because Evas's non-GL display is X11, not Xv, so there would be tearing. So I came up with a nice approach where mplayer runs underneath the evas window. vf_outbuf supports scaling and you can control whether it writes to the shmem buffer, the mplayer video window (i.e. pass the frame to the vo system), or both. So if you want to view an EPG, you tell vf_outbuf "stop rendering to mplayer xv window, and scale the video to 400x300, and start writing to the shmem buffer" and then remap the evas window so it pops up to the foreground. Boom. Instant EPG with hardly any overhead. When you're done, just tell vf_outbuf "stop sending video to the shmem buffer and start displaying it to the vo again" and then unmap the evas window. It's instant and smooth. (There's a very slight flicker with -vo xv that is mitigated if you use a dark colorkey.) With opengl, since it's fast enough to render the full-sized video frame as an evas object, you can do any manner of cool scale/fade/move transitions to bring the EPG (or some other interface) in or out, all dealing with live video. > So what is the interface? It would be cool to have a mevas like > interface to your pyevas so I don't need to rewrite everything. Right now it's a fairly direct mapping of the evas API. I'll probably keep it that way, and add features like containers at another layer. It would be possible to create a mevas-like interface to evas, I think. I haven't fully thought that out, but it should be workable. Some features, like draw_mask(), won't work because, AFAIK, evas's architecture doesn't let you manipulate objects (other than image objects) at the pixel level. But I don't know evas much at all. What I have done with it is more an infinite-monkeys type of thing. > I want a mevas like interface, please. This would be so cool to have > in Freevo. I think I'll leave wrapping it in a mevas API up to you. :) Since you're interested, I'll look at cleaning it up and add it to the libs dir in cvs. > I prefer not to use threads at all, use pynotifier. Threading will add > too much side effects. But if you need Py_BEGIN_ALLOW_THREADS, feel > free to add it. Ok. And, of course, Py_BEGIN/END_ALLOW_THREADS doesn't affect non-threading case. Cheers, Jason. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
