protux-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Protux-devel] code cleanup / general improvements


From: Remon Sijrier
Subject: [Protux-devel] code cleanup / general improvements
Date: Tue, 2 Sep 2003 01:13:15 +0200
User-agent: KMail/1.5.3

Hi,

I think the peak improvements are going to an  and, so I try to do some code 
cleanup / general improvements / bug fixing.

Trying to fix the "flicker" I allready reduced some twice or triple painting, 
but for this, I need your advise:
According the specification a Track = TrackArea + TrackPanel.
Almost all redrawing in Song are done with: recreate_tracks, thus recreating 
all TrackPanels also. This is (with current use and function of TP) not 
necessary, so I added: recreate_track_area, and changed the according calls " 
recreate_tracks". 
Please, let me know if I can upload this change or if it isn't according the 
way protux works not, but for sure, it reduces painting quite a 
bit. 

Ehm, Luciano, you asked why PeakThreadBuilding should be serialized.
All peakBuildThreads are started independently from eachother, and linux tries 
to give an equal amount of cpu time to each thread. If a thread is scanning a 
file, it has to stop and wait for another thread, which also scans a piece of 
a file, and so on, and so on.
This is really killing your hard drive, and the progress meter in the LCD is 
also a mess (displays for all thread at the same time the progress) 
I hope this makes things a bit more clear. Best way to see it in action is: 
Remove before starting Protux, all peakfiles from a Song (e.a. 6 peakfiles) 
and start protux :-)


Other bugs/wishlist: (should I use the BUGLIST for this?)

Following action's give unwanted results when status is "GOING" or 
"any_track_armed while not GOING" :
-goto_begin
-goto_end
-all other such kind of actions

Real Bug (don't know how to solve it):
-Starting a recording in an empty MTA causes the (shuttle?)cursor to act as a 
F1 race car :-)

There's a piece of code in Peak.cc which causes random segfaults. I commented 
it out, I'll upload it, so testing can continue (no automatic redrawing, so 
"Building Peaks" isn't updated automaticaly after peak_build)

Ehm, I have the feeling I forgot something, but for now I'll get some sleep 
:-)

Remon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]