OK, I found it. The crash happens because of this line in my configuration file:
input_device.Core Pointer.width.radius=15.000000
If you remove it or replace it to something like this, then everything is fine:
input_device.Core Pointer.width.radius=15.0000pt
For some reason Synfig expects “pt” at the end of this line and it causes a crash in glibmm.
Packaged synfigstudio uses its own version of glibmm, that’s why the crash happens only for packaged binaries. If you compile form source, then your system glibmm will be used and no crash happen (though, tool parameter panel will display incorrect value for width radius - zero).
Big thanks to genete for helping to track this issue!
There are 2 ways to fix this:
Provide updated/patched version of glibmm with packages
It is due because the width tool radius has units from one change I did. For a new fresh install the crash won’t happen in any case because the configuration file will be written from start.
It should not produce a crash but simply a missing unit recognition and understand that the read value from the configuration are “synfig units” instead of default “points”.
I’ll try to repeat the problem manually editing the configuration at fedora 11 version to see what happen.
Problem confirmed. Crash reproducible.
I’m looking to the code and maybe I can do something. I don’t know if the glibmm is capable of create a string from to iterators that points to a end of a std::string
This is the code where a string is converted to a synfig::distance class (the operator =)
Distance&
Distance::operator=(const synfig::String& str)
{
int i(0);
float val;
int ret(strscanf(str,"%f%n",&val,&i));
// synfig::info("Distance::Distance(): ret=%d, val=%f",ret,val);
if(ret<=0)
{
// Error
synfig::error("Distance::Distance(): Bad value \"%s\"",str.c_str());
return *this;
}
else
value_=val;
synfig::String sys(str.begin()+i,str.end());
if(sys.size())
system_=ident_system(sys);
return *this;
}
If the string (i.e. 15.0000) has not any unit associated, then the string “sys” is created from void:
synfig::String sys(str.begin()+i,str.end());
begin()+i is the same than end(). And then maybe it is there where it crashes.
It may be difficult to debug because the compiled version is using a glibmm that doesn’t crash…
Releases candidates are compiled with debug off. I can run it without any slowness in my ubuntu 9.10 and in ubuntu 10.10 32 bits on a virtual machine. I’ll test it on 10.10 64 bits as soon as possible in the virtual machine.
-G
I can confirm the problem. Latency is very high when re-rendering the scene. I don’t know what’s causing this.
My working environment is a 64 bit system (ubuntu 10.04) and I don’t see any latency even using a virtual machine.
I will do some tests with 11.04 to see if the same problem persists.
I should upgrade my system before attempt to solve it, I think.
Thanks for report it!
-G
This isn’t quite per the git repo. It includes a little bit of tweaking in duckmatic that nikitakit will be submitting to master shortly.
I’ll try and build RC2 tomorrow.
I’ve found some interesting things:
Ubuntu 10.10 under VMware (4 processors, 4 GB ram, 3D rendering display enabled, 1400x1050 monitor resolution) fresh install. I didn’t update it.
Downloaded and installed Synfig Studio 0.63.00 RC2
It doesn’t lag
Closed Ubuntu 10.10 and edit machine settings: 1 single processor, 512 MB ram, not 3D
It does lag. IT DOES HANG THE ENTIRE OPERATING SYSYEM (no response to mouse clicks to any of the windows nor the system menus, ANYTHING!) For example System Monitor also hangs. Memory is not fully used (50%). During lag time (sometimes more than 20 seconds) the assigned processor is 100% in the host machine.
Increase to 2 processors, 512 MB ram, not 3D it does lag.
Increase to 2 processors, 1GB ram, not 3D it does lag.
Increase to 4 processors, 4 GB ram, 3D enabled: It doesn’t lag
Decrease to 4 processors, 4 GB ram, 3D disabled. Doesn’t lag
Decrease to 4 processors, 1 GB ram, 3D disabled it doesn’t lag.
Decrease to 2 processors, 1 GB ram, 3D disabled it does lag … WTF!
Increase to 2 processors, 4 GB ram, 3D enabled it does lag!
Increase to 4 processors, 4 GB ram, 3D enabled it doesn’t lag!
Decrease to 1 processor, 4 GB ram, 3D enabled it does lag!
This is frustrating!
It seems that the number of processors has influence? I cannot test the same failure configuration in a non hosted ubuntu because my computer it 4 processors type. What can I do?
Now I’ve come back to the other 10.10 64 bits virtual machine I had. This virtual machine was initially 1 processor, 512 MB ram and 3D not enabled. But I decided to build Synfig Studio within the virtual machine to see if it has influence. To make building procedure quicker, I increased the number of processors to 4 and the ram to 4GB. Then the lag disappeared…
I’m getting back the number of processors to 1 and I get this:
Packaged Synfig 0.63.00 RC2 does lag. It has hung at start up! and has needed about 20 seconds to recover.
Built binaries also lags with the same amount…
I’ll fully update 10.10 with the suggested packages updates to see if it helps… It will take a while (>300 MB)
Unfortunately it doesn’t help. It lags too.
Definitively two processors or less lags. How can I debug this without a virtual machine???
carbonphobia:
Which video card are you using?
I have tested synfigstudio RC2 in ubuntu 10.10 32bit on dual-core PC, nvidia card. It lags with default drivers, but after I have installed proprietary drivers it’s started to work like a charm.
I guess ubuntu have cairo libraries compiled with optimizations, that heavily rely on the video acceleration. That’s why some users may experience slow down.
In my case Synfig worked out of the box with a fresh clean installation of Ubuntu 11.04 32 bit, my video card is an intel integrated graphci card, with hardware acceleration. is this problem relative to the number of cores like Genete tried to demonstrate or rater to the architecture, 32 and 64 bit?
Intel video cards always have good support for hardware acceleration with native open-source drivers.
As I pointed above, I have tested on 2 core PC, not 4 core, so the case Genete was talking about is probably VmWare issue.
I don’t see how it can be related with 32/64 bit architecture, but I’ll test it on ubuntu 10.10 64bit too.
Also I will see if this behaviour is relevant to ubuntu 11.04.
i found a problem, importing PNG images:
Aparently it has something to do with the alpha channel, this is the original image:
I’m working along with a friend for make an animation, and i wanted to trace this png image inside Synfig, at first i thought it was because the PNG was indexed, but after saving it as RGB the problem was again present. greetings!
Visny:
I can’t reproduce the problem with image attached. Can you please share the .sifz file you are trying to import to? Also, make sure you have default blend method set to composite when importing.
hiya! i’m embarrassed now, it turned out to be the blending mode, but that surprise me a lot because it is set to ‘layer default’ which i assumed it was ‘composite’ all the time unless specified otherwise
Edit: indeed i was right, is because the indexed colors,the image was indexed when imported inside Synfig, could you try again with this image?:
What can I do?
