A BIG WARNING: Those builds are absolutely for testing purposes only. It’s quite possible your files saved using this version might get broken and won’t open in earlier/future versions. Don’t use in production. If you want to install previous snapshots, please get them here - sourceforge.net/projects/synfig … snapshots/
In addition to this Ivan have made changes to the bones behavior - now bone tip allows to change the bone length and angle at the same time (previously bone tip was responsible for changing scale only). Also, he have finished fixing group transformation for software renderer (previously groups were rendered correctly in cairo mode only). There are still some bugs remaining, though.
Here’s how our approximate bone roadmap looks at the moment:
Hello. How do I get to the skeleton layer? I don’t see them in the list of layers even after I enable experimental features, and restart the computer and synfig. I’m using windows 7 64-bit.
Also, with the group layer, I’m a little confused with the origin transformation feature. When i click and try to change the numbers in the parameters, I get “unknown datatype” and can’t type anything in.
Sorry, I haven’t animated in a while, (because of these drawings…ugghh!!!) and I’m rusty and behind on the features.
Very slower than 0.64.1 (in fact it’s slower since single window appear) / core at 100% very often : resizing the panels altering canvas (with empty canvas) / impossible playback of very simple animation / few seconds to select a layer / few seconds for first click by layer in parameter panel (then it’s normaly fluid) /
Same problem with icons.
Segmentation fault after using group rotate handle
Due to the very slow response of the interface i can’t really play and test … sorry
I can’t test this version as I need to stick to the 20131209 build.
The latest build does no longer shows my files correctly - if you animated the Group Origin or Scale in the 20130109 build then these changes are rejected by the latest version and the animation does not appear correctly.
This one is curious. The layers that are rendered using pixel values (those what use get_color() for a position to render the canvas) aren’t rendered in certain nested group. Also they make invisible all the layers at the same group level and below.
See attached file to understand it. Simple circle is a “rasterized” layer. Try to disable/enable the layers called 1, 2 or 3 and you’ll see what I mean.
Ubuntu 10.4.4 / no performance issues, it’s delicious to see how it normaly run compare under debian 7 / kernel 3.2 .
(some third party lib involved maybe?)
When detaching canvas out of main window, the “attach&place” widget stay on main interface
When resizing from vertical right panels, this adjust the toolbox panel, when i expect the canevas panel be resized. To reproduce : reduce the most right panel (to the left) and enlarge it (to the right). ([EDIT131219])
I hate when that happens. I Deleted too many words while editing. I was trying to ask is there a way for Synfig to save where you put ur panels. Everytime you reopen, it resets to its default panel placements.
I can make a special build for you, which will have minimum dependencies on system libraries. So you can test it on Debian and Ubuntu and see if that would make any difference. BTW, when you referring to Debian vs Ubuntu perfomance, do you test it on the same hardware configuration? I mean, does configurations are comparable in terms of count of cores/memory amount?
This is exactly how we made it now - you can modify the tip of the bone in the same way as you modify tangents. This was the change, which triggered a question from Genete ^__^.
I have builded early single window and 0.65dev on debian 7, and everytime they come with performance issues.
Maybe i can try to build has you suggest (how exactly ? building my own third party libs and hard linking them ?), and little by little re-add system dependencies… but, maybe that come from gtk3 migration ? what are news (or new version) libs yvan/single window migration has introduced ?
It’s really different hardware configuration, and the one with debian should be way faster looking at hardware comparaison (dual core vs single , at least twice ram…).
I have quickly tested last 0.65dev (from report 21) on Ubuntu 12.04 MacBook … and it’s fast has expected.