GNOME Bugzilla – Bug 165032
Gimp-Display-CRITICAL on stderr opening 2mp camera jpg image
Last modified: 2008-01-15 12:46:10 UTC
Open an image from a Canon 2mp camera (1600x1200). I'll attach a sample. GIMP prints on stdout: (gimp:2778): Gimp-Display-CRITICAL **: file gimpdisplayshell.c: line 1415 (gimp_display_shell_shrink_wrap): assertion `GTK_WIDGET_REALIZED (shell)' failed once for each image opened, though the image opens correctly. Images from other cameras (higher res, 3mp) open without this error, as do smaller edited images originally from this camera.
Created attachment 36428 [details] Sample image
I tried to load the image but I didn't see any warning message. As it comes from gimp_display_shell_shrink_wrap and the realized signal that was not propagated in time, it looks like a race condition. It probably depends on: - the size of the image compared to the size your screen - the window manager that you are using - the time it takes for the GIMP to open the image If you could provide additional information such as your screen size, WM used, version of GTK+, it may be easier for others to reproduce the problem.
The screen is 1280x1024, wm is fvwm (with "SmartPlacement", and no gimp-specific placement rules), libgtk2 is 2.4.14-2 (debian's). If speed might be an issue, the processor is a P3 1.2GHz and the video card is a Rage128. The images which generate this message are all 1600x1200, a bit larger than the screen. Images (from a different camera) which are larger still, like 2048 x 1536, do not generate the error.
I tested copies of the image at various sizes. I see the error whenever the image is between 1442 and 1921 pixels in width. This is the size range for which gimp shows a big image window, 1002 pixels wide. Above 1921 and below 1442, gimp scales the image window down to a much smaller size, and I don't see the error.
I can't reproduce it either. Running gimp with --g-fatal-warnings and providing the stack trace might help with further diagnosis.
Stack trace from 2.2.3: I'm including the whole thing instead of trying to pick just the relevant parts, because the order in which things are happening might be part of it and maybe something higher up on the stack will give a hint.
+ Trace 54883
This only happens when Resize window on zoom is turned on in the preferences. If gimp_display_shell_new() picks a scale that corresponds to one of the fixed view-zoom actions, and that action is not already set as the default, it falls through this code that tries to shrink wrap a window that doesn't exist yet. Quick fix is to check if the window is realized in gimp_display_shell_scale_resize, but I'm not sure that's the best fix.
Apparently this was fixed by the fix for bug #164281. Added some additional paranoia code to HEAD. Closing as FIXED. 2006-05-07 Michael Natterer <mitch@gimp.org> * app/display/gimpdisplayshell-scale.c (gimp_display_shell_scale): return early if the shell is already at the requested zoom level. (paranoia addition for bug #165032, which was already fixed by the fix for bug #164281)