Fixes for project loading progress display by PhysSong · Pull Request #3672 · LMMS/lmms

PhysSong · 2017-06-29T06:53:06Z

This PR currently includes two commits: first one fixes #3611, second one is enhancement mentioned in same issue. I set base branch to stable-1.2 because of #3611 (comment) by @tresf.
It is okay to decouple two commits if needed(but I don't think the decoupling is needed).

@liushuyu This PR contains a new string which needs translation. Once it is merged, please add it to i18n source string list.
see this.

zonkmachine

I can't properly test f76cb6f as I can't reproduce the issue but it works fine. aee0f2b crashes as commented. You have some lines that go way over the recommended 80 lines. ~170 columns will wrap badly so try and make it shorter.

zonkmachine · 2017-07-03T03:59:22Z

 			!node.toElement().attribute( "metadata" ).toInt() )
 		{
+			QString trackName = node.toElement().hasAttribute( "name" ) ? node.toElement().attribute( "name" ) :
+															   node.firstChild().toElement().attribute( "name" );


125 and 126 too long lines. The coding conventions suggestion for ternary operators is something like this:

QString trackName = node.toElement().hasAttribute( "name" ) ? node.toElement().attribute( "name" ) : node.firstChild().toElement().attribute( "name" );

zonkmachine · 2017-07-03T03:59:47Z

 		{
+			QString trackName = node.toElement().hasAttribute( "name" ) ? node.toElement().attribute( "name" ) :
+															   node.firstChild().toElement().attribute( "name" );
+			pd->setLabelText( tr("Loading Track %1 (%2/Total %3)").arg( trackName ).arg( pd->value() ).arg( Engine::getSong()->getLoadingTrackCount() ) );


It crashes here on command line render. If you wrap it in an if, something like this:

if( gui ) { pd->setLabelText( tr("Loading Track %1 (%2/Total %3)").arg( trackName ).arg( pd->value() ).arg( Engine::getSong()->getLoadingTrackCount() ) ) }

that should fix it.

Also. The line is much too long and wraps badly. Please try and use more lines.

zonkmachine · 2017-07-03T04:09:44Z

Backtrace for crash on command line render

(gdb) bt
#0  QProgressDialog::value (this=0x0) at dialogs/qprogressdialog.cpp:649
#1  0x000000000056882b in TrackContainer::loadSettings (this=0x237dfc0, _this=...) at /home/zonkmachine/builds/lmms/lmms/src/core/TrackContainer.cpp:127
#2  0x0000000000552c0a in SerializingObject::restoreState (this=0x237dfe0, element=...)
    at /home/zonkmachine/builds/lmms/lmms/src/core/SerializingObject.cpp:70

PhysSong · 2017-07-03T04:36:16Z

@zonkmachine Okay. I'll change the code and test it again.

PhysSong · 2017-07-03T05:24:27Z

pd->setValue( start_val + _this.childNodes().count() );(this line) also generated bugs, so I deleted it.
@zonkmachine I fixed code now. Could you test this again?

zonkmachine

Some more convention...

zonkmachine · 2017-07-03T06:21:14Z

+	m_nLoadingTrack=0;
+	for( int i=0,n=tclist.count(); i<n; ++i ){
+		QDomNode nd=tclist.at(i).firstChild();
+		while(!nd.isNull()){


I think the general idea is to put the braces on the same column/tab although I'm not 100% sure about the convention around this.

( .. ) { this }

( .. ){ not this }

zonkmachine · 2017-07-03T06:21:56Z

+			{
+				++m_nLoadingTrack;
+				if( nd.toElement().attribute("type").toInt() == Track::BBTrack ){
+					n += nd.toElement().elementsByTagName("bbtrack").at(0).toElement().firstChildElement().childNodes().count();


A bit too long line here.

zonkmachine · 2017-07-03T06:29:59Z

@zonkmachine I fixed code now. Could you test this again?

Crash fixed!

PhysSong · 2017-07-03T06:32:48Z

How about conventions?

zonkmachine

The rest of the braces too.

zonkmachine · 2017-07-03T06:50:34Z

+	for( int i=0,n=tclist.count(); i<n; ++i )
+	{
+		QDomNode nd=tclist.at(i).firstChild();
+		while(!nd.isNull()){


Here also {

zonkmachine · 2017-07-03T06:51:40Z

+			if( nd.isElement() && nd.nodeName() == "track" )
+			{
+				++m_nLoadingTrack;
+				if( nd.toElement().attribute("type").toInt() == Track::BBTrack ){


And here {

PhysSong · 2017-07-03T07:25:43Z

@zonkmachine I checked coding conventions, and it seems to be fine now.

zonkmachine · 2017-07-03T08:08:35Z

I've tested this and it looks just fine to me. I can also confirm the fix in f76cb6f as I managed to replicate the issue. For me opening the demoproject 'DnB' most clearly demonstrated issue #3611 .

zonkmachine · 2017-07-06T03:27:03Z

Merge?

tresf · 2017-07-06T04:22:53Z

The code look OK. If it's all tested, please merge @zonkmachine. I assume we've tested against a bunch of different project types and that trackName logic won't blow up. :)

zonkmachine · 2017-07-06T16:56:03Z

I assume we've tested against a bunch of different project types and that trackName logic won't blow up. :)

The logic doesn't blow up, but the loading time does however. I thought I had tested for that already... :(
Here's a comparison against loading Skiessi-Onion.mmpz . I believe lmms-1.0.3 might have loaded faster still. @PhysSong As you can see the loading time increases already with your first commit. This is something people have been worrying about already before this PR.
#2029
#3312

Do you see any possibilities to trim it down a bit?

$ time ../stable-1.1.3/bin/lmms ../data/projects/demos/Skiessi/Skiessi-Onion.mmpz 
real	0m3.499s
user	0m2.296s
sys	0m0.200s

$ time ../stable-1.2.0-RC3/bin/lmms ../data/projects/demos/Skiessi/Skiessi-Onion.mmpz 
real	0m5.042s
user	0m3.864s
sys	0m0.224s

$ time ./lmms-aee0f2b ../data/projects/demos/Skiessi/Skiessi-Onion.mmpz 
real	0m8.044s
user	0m6.656s
sys	0m0.288s

$ time ./lmms-097feb0 ../data/projects/demos/Skiessi/Skiessi-Onion.mmpz
real	0m7.291s
user	0m6.584s
sys	0m0.256s

tresf · 2017-07-06T17:03:50Z

Does commenting out the UI call help?

tresf · 2017-07-06T17:07:05Z

I'm also a bit skeptical of iterating mid-for-loop although I haven't placed a debugger on it to see if it can cause problems.

zonkmachine · 2017-07-06T17:55:51Z

No. The commit just before this PR is:

real	0m7.294s
user	0m6.724s
sys	0m0.236s

Somethings happened along the way. I'm trying a bisect.

zonkmachine · 2017-07-06T18:40:26Z

@PhysSong Sorry, it looks like false alarm. I compiled without -DCMAKE_BUILD_TYPE=DEBUG and now get the same time for stable-1.2 and PhysSong:project-load. I thought all my builds were with DEBUG but the one I compared against was not. Without debug the load time I get is about:

time ./lmms ../data/projects/demos/Skiessi/Skiessi-Onion.mmpz
real	0m4.552s
user	0m3.868s
sys	0m0.228s

This PR is all good.

Fix project loading progress jumping back. Show the name of the track currently being loaded.

PhysSong added 2 commits June 28, 2017 14:26

Fix project loading progress backjump

f76cb6f

Show the name of currently being loaded track.

aee0f2b

zonkmachine suggested changes Jul 3, 2017

View reviewed changes

Fix crash and coding conventions

cf90bb7

Remove unused variable start_val

c1d24df

zonkmachine reviewed Jul 3, 2017

View reviewed changes

Fix code conventions

135f65c

zonkmachine reviewed Jul 3, 2017

View reviewed changes

Update Song.cpp

097feb0

zonkmachine approved these changes Jul 3, 2017

View reviewed changes

zonkmachine merged commit c6c67b3 into LMMS:stable-1.2 Jul 6, 2017

PhysSong added a commit to PhysSong/lmms that referenced this pull request Jul 8, 2017

Fixes for project loading progress display (LMMS#3672)

1c21eae

Fix project loading progress jumping back. Show the name of the track currently being loaded.

PhysSong added a commit to PhysSong/lmms that referenced this pull request Jul 8, 2017

Fixes for project loading progress display (LMMS#3672)

7587210

Fix project loading progress jumping back. Show the name of the track currently being loaded.

PhysSong deleted the project-load branch September 4, 2017 14:29

sdasda7777 pushed a commit to sdasda7777/lmms that referenced this pull request Jun 28, 2022

Fixes for project loading progress display (LMMS#3672)

7fbed33

Fix project loading progress jumping back. Show the name of the track currently being loaded.

Conversation

PhysSong commented Jun 29, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zonkmachine left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zonkmachine Jul 3, 2017

Choose a reason for hiding this comment

Uh oh!

zonkmachine Jul 3, 2017

Choose a reason for hiding this comment

Uh oh!

zonkmachine commented Jul 3, 2017

Uh oh!

PhysSong commented Jul 3, 2017

Uh oh!

PhysSong commented Jul 3, 2017

Uh oh!

zonkmachine left a comment

Choose a reason for hiding this comment

Uh oh!

zonkmachine Jul 3, 2017

Choose a reason for hiding this comment

Uh oh!

zonkmachine Jul 3, 2017

Choose a reason for hiding this comment

Uh oh!

zonkmachine commented Jul 3, 2017

Uh oh!

PhysSong commented Jul 3, 2017

Uh oh!

zonkmachine left a comment

Choose a reason for hiding this comment

Uh oh!

zonkmachine Jul 3, 2017

Choose a reason for hiding this comment

Uh oh!

zonkmachine Jul 3, 2017

Choose a reason for hiding this comment

Uh oh!

PhysSong commented Jul 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zonkmachine commented Jul 3, 2017

Uh oh!

zonkmachine commented Jul 6, 2017

Uh oh!

tresf commented Jul 6, 2017

Uh oh!

zonkmachine commented Jul 6, 2017

Uh oh!

tresf commented Jul 6, 2017

Uh oh!

tresf commented Jul 6, 2017

Uh oh!

zonkmachine commented Jul 6, 2017

Uh oh!

zonkmachine commented Jul 6, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

PhysSong commented Jun 29, 2017 •

edited

Loading

zonkmachine left a comment •

edited

Loading

PhysSong commented Jul 3, 2017 •

edited

Loading