Subject:Display problem

Posted by: pbeshuk

Date:9/1/2003 8:20:14 PM

Whenever I do File-Open or File-Save, I get 2 blue "progress" bars and 2 Cancel buttons at the lower left of the Sforge display. It also happens during "Building Peaks". The 2 blue progress bars move perfectly in unison. Is there any reason for this?

thanks.

Subject:RE: Display problem

Reply by: Chienworks

Date:9/1/2003 10:21:03 PM

Dunno. It started with Sound Forge 5.0. I quickly learned to ignore it. It hasn't seemed to cause any problems. It just looks kinda weird until you get used to it.

Subject:RE: Display problem

Reply by: msterlin

Date:9/2/2003 11:20:47 AM

I can't remember where I read the explanation but it has to do with the fact that SF is now multi-threaded. The top progress bar represents the overall operation and the lower progress bar represents the sub-operations. When all of the sub operations have completed, the top progress bar will then move - in your case there is only one operation so they move in unison.

If you extract multiple tracks from a CD (say 1-5), the top progress bar will say 'Extract from CD xxx - Track 5' while the bottom one cycles thru 1-4. When tracks 1-4 have completed, then the top progress bar will move. Of course, the top progress bar really should move incrementally as each of the sub operations is completed, but that is not how they implemented it.
I'm guessing they spin one thread for each operation and wait for them to join the main thread that started it all - only then do they update the display of the top progress bar which is why it never moves until all operations are done.

Subject:RE: Display problem

Reply by: msterlin

Date:9/2/2003 11:36:53 AM

Just to clarify my last post using cd audio extraction as an example: there are probably only two threads for that example - one for the overall operation and one for each track. The main thread will extract the last track and the seond thread will extract the others one by one. So the main thread is initially blocked, waiting for the other to complete. When the second thread joins the first, the first thread does its extract and thus the overall operation is complete. I actually like this new behavior, but think the top progress bar should move incrementally as each sub operation is completed.

Subject:RE: Display problem

Reply by: Sonic

Date:9/2/2003 3:08:39 PM

Not quite right. The one on the frame is for file operations and global to the app. It only does one thing at a time, like cd ripping, file rendering, proxy building, etc.

The one in the datawnd mirrors it since the datawnd is locked out til it completes. Other processing operations occur on a different thread and only show progress on the datawnd being processed.

If you didn't have the datawnd maximized it would be clearer. The frame progress is only particularly necessary when, say, you are doing a render in one window then continue working in another while maximized.

J.

Subject:RE: Display problem

Reply by: msterlin

Date:9/2/2003 4:01:05 PM

Thanks for the clarification Sonic. I was just guessing based on what I was observing. So if there were multiple file operations going, such as one rip and one load from disc, the global progress bar should show the combined status of those two operations? I'll have to try it and see. :)

I guess I assumed that there was one dedicated thread for the global progress bar that got events from other worker threads (one per data window) to show the current level of completion of all work.