From: Paul G. <dr...@gm...> - 2007-09-18 18:57:05
|
I remember, a while ago, people were complaining about how long it took to load a song. (Or even unload a song). I think this was around the time we went to the zipped project files. Anyways, the big problem was creating TONS of Widgets (controls). We have to create a new window for each instrument. Then, there are 4 tabs on each window with dozens of widgets in each. And let's not get started with the widgets contained in some of the instrument plugins. My original thought was to create a pool, or some sort of cache for these instrument windows/dialogs. Or, at least a deep-copy constructor that may perform faster than constructing from scratch. Fast forward to now. QT4 is nice, but slow. We have a bunch of channels/insruments with a bunch of controls and each control is SLOW. Quasi-Big-O-Notation says: O(n*n*slow) =3D "Sucks alot". Now, let me ask you this: How many instrument windows do you have open at a time? How many instrument windows do you actually need open at a time? Finally, doesn't have 20+ instruments open at a time get very cluttered very fast? and doesn't it give you a seizure with all the widgets automating every which way? We have one song editor. We have one beatline editor. We should have one instrument window at a time. This way instead of O(n*n*slow) we have O(slow) which =3D "tolerable". This is what FLStudio does, and I've never heard anyone complain about that. Construction/Destruction will be alot faster. Sure, some plugins will need to be redesigned slightly, or we may just need to manage it better at at widget-level. Every instrument creates it's GUI on startup, and it uses Knob-values and stuff in the calculations. So, either the instruments must defer UI creation, and use variables in addition to knobs. Or, we need to allow controls such as Knobs to exist in a sort of abstract state where all they have is a value, but they do not redraw, they have no parent, etc.. Then we fix the UI when the user tries to few the PLUGIN tab. Just some food for thought.. -Paul On 9/18/07, Tobias Doerffel <tob...@gm...> wrote: > Am Dienstag, 18. September 2007 17:48:05 schrieb default user: > > Just curious because i couldn't seem to find any estimations on when it > > will be ready. Anyone know how progress is coming? Thanks, i'm just a b= it > > curious and excited for the new release. -cbrooks > Don't expect too much! It's the same as with KDE4 - it's hyped like it's = a big > revolution but in the end not that much things will change that directly > affect the user. Instead the technologies behind the scenes are > improved/rewritten a lot. Due to changes/performance-decreasements in Qt4= the > GUI of 0.4.x currently runs much more slow than in 0.3.0. I even don't kn= ow > whether this will/can be fixed. > > LMMS 0.4.x will make use of some of the new technologies of Qt4 and will = have > a more clean code-base, however at least in 0.4.x almost no new features = will > be added. I can't say when 0.4.x (SVN-trunk) will be usable but I think a= ll > basic work will be done within this year. > > toby > > -- > Freiheit statt Angst -- Stoppt den =DCberwachungswahn! > Demo in Berlin, Samstag 22.09.2007 > www.freiheitstattangst.de > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > > |