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.
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
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?
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
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);
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.
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);
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?
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 ?
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.
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.
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