Jason Tackaberry wrote: >> 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. :)
That's how I looked at the code :)
>> 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. :)
/me is using emacs
> 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.
inotify sounds nice. But it requires a special kernel build. So I
guess it should be optional in Freevo. But is sounds much better than
polling directories for changes.
For Freevo I was thinking different. I create metadata and thumbnails
on the fly when it's needed or use the cache helper to create it
before. What I found interesting is the sqlite db. I played with
sqlite and found using a directory pickle file much faster for normal
operations like "go into a directory". But I still need some sort of
database or index to do stuff like "show all mp3 files from 2001".
> Where the vfs directory is not an actual filesystem directory but a
> database query
OK, this sounds like your vfs is called mediadb in Freevo cvs.
> 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.
I don't like datbases right now, they seem slow. For a huge guide, the
epg database is slower than it should be. And for a mediadb, the index
can be huge.
> 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.
inotify works with select, so why is there a problem with directory
monitoring? File indexing may take some time, but in Freevo creating
metadata and thumbnail is very fast for one file. It's only slow if
you enter a new directory with too much files.
> I tend to shy away from threads too, though. Things are extremely
> difficult to get right.
I try to avoid threads as much as possible. We had two bad bugs in
older versions of Freevo. Users reported the bug and I couldn't
reproduce it. That's makes it hard to find bugs.
>> 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. :)
Mbus is also very small. It only requires pyNotifier, but every app
needs a main loop, so that's what pyNotifier is for. The real main
loop is only one file in pyNotifier, you only have more files because
it is possible to ride on gtk main loops and others using the same
interface.
>> 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.
Great. It would help if I have something liek the ImageCancas. I need
an imlib2 image, draw on it and put it into evas. Everything else
would be easy to rewrite, only the creating of objects is used very
often. Is it possible to create an evas object from an imlib2 image?
Dischi
--
++?????++ Out of Cheese Error. Redo From Start.
-- (Terry Pratchett, Interesting Times)
pgpFu1SWrprTU.pgp
Description: PGP signature
