Mercurial > audlegacy
view TODO @ 4709:983a24dab128
update Japanese translation.
author | VDR dai (audacious) <d+audacious@vdr.jp> |
---|---|
date | Tue, 08 Jul 2008 11:29:29 +0900 |
parents | e36c207de2c1 |
children |
line wrap: on
line source
Long-term "TODO" ================ - output plugins should have some kind of (optional) "query available formats" function, so that the core could determine what should be used. perhaps offer users this info? - remove the idiotic XMMS compatibility output plugin hack. - all audio plugins (input, output, effect) should be made completely re-entrant. this probably means severely breaking the API. not very trivial either :( * basically plugin init() should allocate / init a state struct to be used in all operations, etc. - the equalizer should be fixed .. in more than one way: * equalizer was broken by asphyx's libSAD * lots of things are hardcoded, like number of EQ bands. this should be changed. - URIs with "?" are stripped (the subtune support uses that), which is bad, because some (a lot) of real-world URLs use 'GET' arguments. this breaks probing, but current input probing is confusing (and possibly broken anyway) and should be refactored. - mime-types support: * there is already code for mime support, but I think it may not be sufficient as it is designed for input plugins only -- also playlist containers etc. need this (IMHO) * might be nicer to have the type registrations in plugin struct instead of a separate function, a'la vfs_extensions. - document the different APIs via Doxygen - unified debugging/message system, for core and plugins * something like glib logging system, with logging levels * hardcoded "debugging" levels and/or macro-wrappers that would disable superfluous debugging output compile-time. --- being planned by ccr - audacious VFS is not 64-bit offset safe, breakage will most likely occur, if files larger than 2^31 are used (rather unlikely, tho, but still...) * nenolod says: current vfs sucks, it needs a "rewrite": - buffering support - non-blocking I/O support - {core,plugins}/configure.ac need some cleanup loving. * make session management (SM) optional. (done) * build system cleanups .. extra.mk.in? wtf? (done in core, progressing for plugins) --- this is in progress, worked on by ccr - plugin rewrites: * madplug * modplug (in progress by ccr) * scrobbler Playlist code issues ==================== It's been determined that the playlist code should be completely refactored. ATTENTION! Add more stuff here! Issues that you can think of, suggestions for solutions, etc. References to algorithms... - code (mostly in playlist.c) is unnecessarily complex in some places and there is lots of useless duplication. - what data structures should be used? things that factor in are efficiency and scalability - memory usage and speed. see also below and notice the manipulation bottleneck(s). (different structures typically have bottlenecks in different places.) - playlist_clear() is VERY slow with large playlists, possible reasons? * GList scalability sucks? (it does, but is it the real reason here? need to profile this...) * maybe playlist_entry_free() is at fault instead? (see also below) * mowgli_heap_free()? possible solutions? * mempools for playlist data? not sure if possible, the tuple heaps should then somehow be collected into pools... * storing the playlist as a GtkTreeModel seems to be fairly fast (at least in mudkip-player it is) --nenolod - current implementation has a nasty racecondition in scanner thread vs. playlist manipulation (playlist_clear(), free, etc.) * new code should be water-tight when it comes to locking. simpler code with more "atomic operations" should help. ccr rants: ---------- I suggest that the whole playlist manipulation should be moved into separate thread. What I mean, is that the playlist scanning (e.g. probing for metadata) AND adding files into playlist should be in a thread. Adding files would work like this: 1) feed URIs to playlist handler thread 2) playlist handler notices new URIs and starts checking if they are valid aka probing or other checks. 3) valid files/URIs get added to the playlist. unsupported files get discarded. Possible benefits of this approach: - checking for "can we play this?", which currently happens in main thread and blocks the GUI etc, would now happen asynchronously. - improved user experience: less blocking generally, and it would be even possible to _parallelize_ probing, if we wanted to, getting metadata for multiple files at the same time. (this could be a user-settable option.) Bad sides: - requires careful design and thread locking .. but that we need anyway. - possibly might make playlist GUI representation harder. I am not sure what effects this might have, feel free to pitch in thoughts...