Monday, 8 October 2007

Introspection

Tell me we're not going that way! That's why Totem is just a movie player. I hope we can manage to keep it simple and fast (although the Python plugin support does nothing for its startup speed I've been told).

8 comments:

DrBob said...

My baseless musing goes straight from IRC and into a blog, I see.

That's efficiency for you. :-D

hadess said...

Next time, blog it yourself :)

Anonymous said...

Fast must be the last thing I think of when I use Totem.

I tend to select a bunch of files, and press enter. Totem reads info from all files before it starts to play the first one. This alone makes is very slow when starting it this way.

Threading doesn't seem to have been on there mind when writing it.

Jochen

hadess said...

It only checks the mime-type of the files to be added, which is at most 1k of data, before starting. That's it.

Anonymous said...

For what it's worth, the pattern that links all those programs seems to be commercialization... features were added or removed to suit the marketing people.

Totem is hopefully much less susceptible to such forces.

Anonymous said...

mime-type parsing can be a performance problem because of hard disk seeks, especially if the system has a slow hard disk, is very fragmented, is swapping, etc.

Don't know how much of a real performance hit it's in totem, but anyway... Wouldn't it be better to start playing the first file and read the mime-type for the rest in the background?

nicu said...

I agree about the focus on "movie player" and simplicity of the interface, but at the same time Totem is also may music player of choice (Rhythmbox is overkill for me), so I wouldn't mind a few more music features..

Anonymous said...

hadess, as someone mentioned before me. This is not the best way to do it.

Simple test, start one song, start up time is 4 seconds, start 100 songs, start up time is 44 seconds on my system...

100 files is not such an uncommon use case.