GNOME Bugzilla – Bug 690236
eog shows (small) pictures at 96% (and 97%) zoom, instead of (easily achievable) 100%
Last modified: 2013-12-05 23:18:34 UTC
In nautilus I hit Enter on a jpg (which is smaller than the screen). The jpg appears at 100% zoom, and eog's window around it - without the menu bar yet. Then, just a moment afterwards, the menu bar appears, eog resizes the picture [not the window!] - to 96% or 97% zoom ratio. Everybody wanted to view pictures at 100% zoom (if possible).. I use an old-fashioned gnome: "/usr/bin/gnome-session --session=gnome-fallback". Ambiance theme.
I see this too: images open at 98% or 99% rather than at normal size. I'm running Eye of GNOME built from git master (last released at version 3.8.2).
I have this to an ever more extreme extent. When I open an 1024x768 picture on my full-hd screen, eog shows it a 99%. Almost like an off-by-one. It smells like that eog doesn't compensate for its window decorations eog 3.8.2 on F19
Confirmed with Fedora 19: eog-3.8.2-2.fc19.x86_64 When a VM screenshot is slightly downsized by eog, text may become corrupt or unreadable. Screenshots illustrating the problem are attached here: Bug 1000987 - image scaled to 99% instead of 100% https://bugzilla.redhat.com/show_bug.cgi?id=1000987
Still buggy in 3.10.0. I think an image will load at 100% if the toolbar is hidden (even though the screen is large enough for the image at 100% with the toolbar visible). output with EOG_DEBUG_WINDOW on loading a 1033x557 image: [0.052464 (0.052464)] eog-window.c:5585 (eog_window_new) [0.054194 (0.001730)] eog-window.c:4975 (eog_window_init) [0.160068 (0.105874)] eog-window.c:3940 (eog_window_cmd_zoom_fit) [0.165068 (0.005000)] eog-window.c:596 (update_action_groups_state) [0.167827 (0.002759)] eog-window.c:1967 (update_ui_visibility) [0.168140 (0.000313)] eog-window.c:5711 (eog_window_open_file_list) [0.177841 (0.009701)] eog-window.c:5627 (eog_job_model_cb) [0.194638 (0.016797)] eog-window.c:596 (update_action_groups_state) [0.221422 (0.026784)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 495, 100 Bar: 13, 13 [0.237866 (0.016444)] eog-window.c:1261 (eog_window_obtain_desired_size) Setting window size: 1033 x 641 [0.261068 (0.023202)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 557 Bar: 0, 0 [0.264989 (0.003921)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 557 Bar: 0, 0 [0.298902 (0.033913)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 549 Bar: 0, 0 [0.299169 (0.000267)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 549 Bar: 0, 0 [0.307909 (0.008740)] eog-window.c:1308 (eog_job_load_cb) [0.308176 (0.000267)] eog-window.c:883 (eog_window_display_image) [0.317528 (0.009352)] eog-window.c:509 (update_status_bar) [0.317958 (0.000430)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 549 Bar: 0, 0 [0.319072 (0.001114)] eog-window.c:509 (update_status_bar) [0.337738 (0.018666)] eog-scroll-view.c:1819 (display_draw) zoom 0.99, xofs: 7, yofs: 0 scaled w: 1018 h: 549 [3.437807 (3.100069)] eog-window.c:5037 (eog_window_dispose) [3.437880 (0.000073)] eog-window.c:1773 (fullscreen_clear_timeout)
Could be due to some changes in Adwaita (the titlebar is slightly bigger I think). :( Really need a way to get the decoration size programmatically...
It's equally buggy using the built-in Raleigh gtk theme, except that the height ends up getting decreased by 2 pixels rather than 8, and then eog doesn't show the vertical scrollbar and puts 100% in the statusbar, although the image isn't actually at being shown at 100%. [0.291108 (0.026026)] eog-window.c:1261 (eog_window_obtain_desired_size) Setting window size: 1033 x 667 [0.342313 (0.051205)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 557 Bar: 0, 0 [0.343972 (0.001659)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 557 Bar: 0, 0 [0.377737 (0.033765)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 555 Bar: 0, 0 [0.377990 (0.000253)] eog-scroll-view.c:445 (check_scrollbar_visibility) Widget Size allocate: 1033, 555 Bar: 0, 0
Did some debugging at it seems like the toolbar is causing the problems this time. It seems to expand vertically AFTER we already calculated the window size. Not sure why yet, but could you peoples please try if it works if you hide the toolbar (if you can reproduce it)? That would ensure that we are all talking about the same problem.
when I turn off the toolbar it shows the pictures correctly on all the ones that I tried where the problem is shown with the toolbar on
Hiding toolbar works around the bug here (Ubuntu 13.10 w/Unity default theme and eog 3.8.2).
Hi, i am lured from Bountsource. As comment #7 said, the height of the toolbar is changing after the initial calculation. This can be easily seen with. EOG_DEBUG=1 GTK_DEBUG=geometry eog image.png There is warnings of attempt to underallocate the toolbar's children. With further tracing was found, that this is related to toolbar style property "border-width". Using a custom theme style and setting: GtkToolbar { border-width: 0px; } the window gets the size that allows the image to have 1:1 zoom, any value not zero and this bug shows. What is to believe to be happening is that. In eog_window_obtain_desired_size, forcing gtk_widget_realize, to get gtk_widget_get_allocation, is returning the allocation size without counting for the toolbar's border-width, as if border-width is always 0px. In other words, with gtk_widget_realize, the theme style is not been correct applied. This is not a bug in eog, but in libgtk+3 caused by the moving from old style to new css based styling? gtk+/gtk/gtkwidget.c:gtk_widget_realize G_GNUC_BEGIN_IGNORE_DEPRECATIONS; gtk_widget_ensure_style (widget); G_GNUC_END_IGNORE_DEPRECATIONS; Is using a deprecated function. And the style is correct applied after because of the gtk_window_show has this. gtk+/gtk/gtkwindow.c:gtk_window_show empty = _gtk_bitmask_new (); _gtk_style_context_validate (gtk_widget_get_style_context (widget), g_get_monotonic_time (), 0, empty); _gtk_bitmask_free (empty); If adding the above _gtk_style_context_validate, to the function gtk_widget_realize, compile and run eog under this patched libgtk+3, this bug doesn't happen. But only a developer familiar with the gtk+ internals, can say if this is a correct fix. This deserves a bug filling in gtk+, i will do so when time allows.
Should eog do a workaround? I can see two possible ways. 1. Rework eog_window_obtain_desired_size, to not rely in gtk_widget_realize, maybe wait instead for the "realize" signal. 2. Add to EogScrollView the ability to start with a prefered size.
Bug filled in gtk+ https://bugzilla.gnome.org/show_bug.cgi?id=715163
(In reply to comment #11) > Should eog do a workaround? > > I can see two possible ways. > 1. Rework eog_window_obtain_desired_size, to not rely in gtk_widget_realize, > maybe wait instead for the "realize" signal. > > 2. Add to EogScrollView the ability to start with a prefered size. Thanks for the deeper analysis Marco. I think we should see what the GTK devs think about it, before working it around.
Hi Marco, did you ask about this on #gtk+ on irc.gnome.org, rather? I'll be surprised if you get a response about GTK+ on bugzilla...
(In reply to comment #14) > Hi Marco, did you ask about this on #gtk+ on irc.gnome.org, rather? > I'll be surprised if you get a response about GTK+ on bugzilla... Well there was a reply. I will try to find more details about what is happening to have more concrete arguments. There isn't a point to go to irc without knowing what to say.
Now, i am lost. Should then a work around be done?
--- a/cut-n-paste/toolbar-editor/egg-editable-toolbar.c +++ b/cut-n-paste/toolbar-editor/egg-editable-toolbar.c @@ -1072,6 +1072,8 @@ create_dock (EggEditableToolbar *etoolbar) gtk_widget_show (toolbar); gtk_box_pack_start (GTK_BOX (hbox), toolbar, TRUE, TRUE, 0); + gtk_style_context_invalidate (gtk_widget_get_style_context (toolbar)); + g_signal_connect (toolbar, "drag_drop", G_CALLBACK (toolbar_drag_drop_cb), etoolbar); g_signal_connect (toolbar, "drag_motion", This fixes it, but is not acceptable, that is why is not posted as attachment, and more over that function is deprecated in gtk+ 3.12 Do someone has suggestions in the way to proceed? Spend time to find out why gtk+3 behaves this way, only to be likely again told that is the expected behavior.
Marco, what happens if the border-style property in play here is changed to "solid" in Adwaita? Does that fix it?
(In reply to comment #18) > Marco, what happens if the border-style property in play here is changed to > "solid" in Adwaita? Does that fix it? No effect. But you made me to repeat again, and i found a new behavior related to css selectors. If selector is: GtkToolbar OK GtkToolbar.toolbar NOTOK .toolbar NOTOK Any properties defined without selector GtkToolbar, this bug happens. Example that works: GtkToolbar, GtkToolbar.toolbar, .toolbar { border-width: 11px; }
--- a/gtk/gtktoolbar.c +++ b/gtk/gtktoolbar.c @@ -675,6 +675,9 @@ gtk_toolbar_init (GtkToolbar *toolbar) GtkToolbarPrivate *priv; GtkStyleContext *context; + context = gtk_widget_get_style_context (GTK_WIDGET (toolbar)); + gtk_style_context_add_class (context, GTK_STYLE_CLASS_TOOLBAR); + toolbar->priv = gtk_toolbar_get_instance_private (toolbar); priv = toolbar->priv; @@ -711,9 +714,6 @@ gtk_toolbar_init (GtkToolbar *toolbar) priv->max_homogeneous_pixels = -1; priv->timer = g_timer_new (); - - context = gtk_widget_get_style_context (GTK_WIDGET (toolbar)); - gtk_style_context_add_class (context, GTK_STYLE_CLASS_TOOLBAR); } get_button_relief calls gtk_widget_style_get that creates the style context for this widget, but this was happening before the style class "toolbar" is added to the widget. I will fill the bug in gtk+ tomorrow. Can someone test to confirm?
If someone confirm this fix, please comment here: https://bugzilla.gnome.org/show_bug.cgi?id=719595
I can confirm that this EOG bug does not occur when GTK is built with the patch in bug 719595. Thanks!
The GTK bug has now been fixed, so I think we can now close this bug. Can one of the EOG maintainers (or the original reporter, Komka Péter) do that?
Okay, thanks for the great analysis Marco. :) Let's consider this fixed as of GTK+ 3.10.6 (stable) and 3.11.3 (unstable). --- This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Made master depend on GTK 3.10.6 to avoid this. commit cdda72568d1e217f682a77a9857aff163d40ab16 Author: Felix Riemann <> Date: Fri Dec 6 00:14:41 2013 +0100 Raise GTK+ dependency to 3.10.6 This is to avoid a bug in previous GTK versions that caused the window to be too small and unnecessary scale images down. https://bugzilla.gnome.org/show_bug.cgi?id=690236