I’ve read in the IRC logs and other comments in somewhere, that adding a Keyframe (the first one) produces a crash.
Can anyone reproduce it and specify a operating system where it happens?
I can’t reproduce in OSX 10.8 or Linux Mint 14 64 bits.
-G
Look like mine …
viewtopic.php?f=1&t=4266&start=0#p18929
This crash, in my case, has went alone : could be a third party buggy update of some system package, who now is corrected.
Look like mine …
viewtopic.php?f=1&t=4266&start=0#p18929
I have done a personal patch …
now (since two days) i don’t need no more my path.
This crash, in my case, has went alone : could be a third party buggy update of some system package, who now is corrected.
OS: Linux Ubuntu 12.04
Synfig: synfigstudio 0.64.0-20130509.master.8
Crashes when creating a keyframe at anytime after I select the “+” icon. Funny cause it worked when I first installed and played with BasicKnightRider tutorial example I generated. Now when I download and open it, then try to create a new KeyFrame, it closes immediately.
the “add keyframe crash” come back …
system config : debian wheezy, kernel 3.2.0-4-686-pae , xfce 4.8
Was fine before on same config.
Now, after system uptodate, and some extra packages in order to build anjuta 3.8.4
( libgdl 3.5, vte-2.90 dev , libgtksourceview-3.0-dev , itstool , libsqlite3 dev )
and also a :
perl -MCPAN -e install Locale::gettext
(to resolve “lib not portable” compilation problem) ,
synfig crash when i try to activate (check box) or add a keyframe…any action who require “Widget_Keyframe_List::redraw()” ,
BUT not during the call to create the first keyframe in a new document !!!
So now in order to add a keyframe to synfig i need to comment (//)
get_window()->draw_rectangle(gc, true, 0, 0, w, h);
from synfig-studio/src/gui/widgets/widget_keyframe_list.cpp:107
see(:ya!
Hi djay,
is the crash is produced in a development version or the final 0.64 binaries? Since you comment that you can avoid the crash when comment that line in widget_keyframe_list.cpp, I guess that you’re working with your development version.
Notice that, as fas as I know, the bundled version carries on all the libraries that it uses, so the installation of the new libraries shouldn’t affect the bundled version. On the other hand, I’m aware that your system uses the bleeding edge libraries versions that are used when create your own binaries.
The crash on the line of the drawing of the rectangle using the old and deprecated ‘gc’ (in opposition to the Cairo one) makes me think that we should use Cairo on those drawings operations instead of keep using the old graphic context (gc) or simply comment that line, isn’t it? 
-G
both version (from 0.64.0 binary and my development version) crash … that should come from and third party lib…
humm, since more in user interface part , gtk, that the bug is around… during the “draw a [grey] background” … the ‘patch’ result visually in a white background in
the keyframe widget area … but can be more mysterious… for quite sure nothing related cairo or synfig render
synfig-studio/src/gui/widgets/widget_keyframe_list.cpp:100
[code]bool
Widget_Keyframe_List::redraw()
{
const int h(get_height());
const int w(get_width());
//!Boundaries of the drawing area in time units.
synfig::Time top(adj_timescale->get_upper());
synfig::Time bottom(adj_timescale->get_lower());
//! The graphic context
Glib::RefPtr<Gdk::GC> gc(Gdk::GC::create(get_window()));
//! A rectangle that defines the drawing area.
Gdk::Rectangle area(0,0,w,h);
//! draw a background
gc->set_rgb_fg_color(Gdk::Color("#9d9d9d"));
//get_window()->draw_rectangle(gc, true, 0, 0, w, h);
…
[/code]
see(:ya!
This issue affects me as well - I haven’t been able to pin down exactly when it happens. It happens randomly (not consistently) after I click the “Add Keyframe” button, and occasionally when I delete keyframes. I had no problem in the previous version. but 0.64.0 has this issue.
System:
Ubuntu 13.04, 64bit (latest updates installed)
Synfig 0.64.0 (downloaded from Synfig website)
Sam43… : can you search for version of libgtksourceview and libgdl you have … ?
/ extra info /
pkgs.org/search/?keyword=libgtksourceview
pkgs.org/search/?keyword=libgdl
Any news on this bug? Ubuntu 12.10 version 0.64.0
thanks
After some little exploration inside that issue,
sometime, for some reason, gtkwidget::getwindow() return NULL .
i have better patched my case with an initinal test : if(!getwindow()) return false;
and so have the keyframe widget background drawned
[code]bool
Widget_Keyframe_List::redraw()
{
if(!getwindow()) return false;
const int h(get_height());
const int w(get_width());
//!Boundaries of the drawing area in time units.
synfig::Time top(adj_timescale->get_upper());
synfig::Time bottom(adj_timescale->get_lower());
//! The graphic context
Glib::RefPtrGdk::GC gc(Gdk::GC::create(get_window()));
//! A rectangle that defines the drawing area.
Gdk::Rectangle area(0,0,w,h);
//! draw a background
gc->set_rgb_fg_color(Gdk::Color("#9d9d9d"));
get_window()->draw_rectangle(gc, true, 0, 0, w, h);
…[/code]
even if this issue do not affect everybody,
i think i’ts a real one …
see(:ya
get_window() returns null in case the window is not realized. Maybe we are calling redraw without being sure that the window is realized? Redraw should be called only by the windows manager when it needs to update a window (widget). We should only send signals to the gtk manager that the widget is dirty and that is has to be redrawn (when possible).
Also, wouldn’t it be good to migrate those drawing operations to Cairo since it is the standard drawing system in the newest Gtk/Gtkmm versions?
-G
- has redraw is called on exposure signal , add / remove / change / keyframe (see Widget_Keyframe_List::set_canvas_interface) , sometime the
window can be not ready.
I don’t know if it’s possible to prevent that situation, so i think that the getwindow() test if a good things.
edit (few’mins’lat’) I just found the same test in the gtkmm murray cumming book (page 201), so this is not so rare
MyArea::on_expose_event(GdkEventExpose* event)
{
// This is where we draw on the window
Glib::RefPtr<Gdk::Window> window = get_window();
if(window)
{
Gtk::Allocation allocation = get_allocation();
const int width = allocation.get_width();
const int height = allocati
- migrate drawing to cairo … yep, it’s a good idea… little postit on buggennie ?
see(:ya!
Perhaps something similar needs to be added to the main canvas window - that seems to crash randomly as well when you move through the timeline too quickly. It sounds like the same thing is happening - GTKmm is trying to update the canvas window before it’s ready.
Don’t ask such things! Just do it!
And good catch on the window existence. I’m sure it happens in more places as DaveJ suggested.
Good work!
-G
I’m getting the same crash under Xubuntu 12.04. This is a pretty serious bug as it seems to render the software virtually useless unless there is some workaround I’m not aware of. I hope this is fixed soon. I’m working on a motion comic right now, and I’m by necessity starting to investigate other options. I don’t want to, because this seems to be the best tool out there right now.
i want to say “yes” and also for the fixy .
Has you saw, the bug is isolated and fixed in some dev version (at least in my dev)… should be integrated soon.
Well done.
I just used the most recent snapshot version and it is still crashing under Xubuntu 12.04. Though now it is actually listing the first key frame at 0s which the recent release does not.
I’m not a coder, so I’m just making a guess here, but if crash bug is related to GTK, would a hotkey command be a possible solution? I noticed in the wiki manual that there are command keys for many functions, but there doesn’t appear to be one for adding a keyframe. Unless this feature was already added but not included in the documentation.
“Normal”, the patch for keyframe crash was accepted yesterday ( sourceforge.net/p/synfig/mailman … /31360617/ ) wait a little for new dev’ version update , jump to the fantastic world of building your own dev’ snapshot, or expect for 0.64.1 ship out.
yep … it’s the case, but nop, a shortcut trick do not solve the redraw crash