[virt-tools-list] [PATCH virt-viewer] Don't resize guest display on zoom change

Jonathon Jongsma jjongsma at redhat.com
Wed Mar 12 20:54:23 UTC 2014


still need review on this.  haven't noticed any regressions in the past week.


----- Original Message -----
> From: "Jonathon Jongsma" <jjongsma at redhat.com>
> To: virt-tools-list at redhat.com
> Sent: Thursday, March 6, 2014 4:15:25 PM
> Subject: [virt-tools-list] [PATCH virt-viewer] Don't resize guest display on	zoom change
> 
> When the zoom level is changed, the virt-viewer window gets resized. But we
> don't want this to trigger a resize of the guest display. But occasionally
> rounding errors cause the guest display to be reconfigured when zooming out.
> To
> fix this, we first check whether the current size is the preferred size.  If
> it
> is, we don't send down a resize command to the guest.
> 
> In addition to preventing guest resizes in response to zooming, it also
> improves
> the behavior when the guest display resolution is changed from within the
> guest.
> Before this change, we'd have the following behavior:
>     A. guest changes display to WxH
>     B. client gets notified of change and resizes the window to WxH
>     C. client responds to window resize by sending a new monitor config
>     command to the guest
> 
> With this change, the extra step C will be avoided because we're already at
> the
> preferred size.
> 
> Resolves: rhbz#1004051
> ---
> 
> Here's a more complete patch that doesn't cause the regression I mentioned in
> the last email.
> 
> A quick description of the regression: when more tha one display was enabled,
> the displays would initially show up at the right size and then be resized
> down
> to very small (<400x400) size.
> 
> Quick summary of the cause of the regression: windows are created with a
> default
> size of 400x400.  When the display is initially added to the window and
> shown,
> it will cause an initial allocation of slightly less than 400x400, followed
> by a
> resize to the actual the size of display. It's a bit surprising that this
> ever
> worked properly, but my previous patch was enough to violate some
> assumptions,
> causing it to break.
> 
> The solution is to ignore all allocations that happen before the widget is
> mapped to screen. We really don't want to be sending guest resize commands
> due
> to allocations that aren't due to explicit user actions.
> 
> 
>  src/virt-viewer-display-spice.c | 21 ++++++++++++++++++++-
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/src/virt-viewer-display-spice.c
> b/src/virt-viewer-display-spice.c
> index d13fbda..a803ab0 100644
> --- a/src/virt-viewer-display-spice.c
> +++ b/src/virt-viewer-display-spice.c
> @@ -190,9 +190,28 @@ virt_viewer_display_spice_mouse_grab(SpiceDisplay
> *display G_GNUC_UNUSED,
>  
>  static void
>  virt_viewer_display_spice_size_allocate(VirtViewerDisplaySpice *self,
> -                                        GtkAllocation *allocation
> G_GNUC_UNUSED,
> +                                        GtkAllocation *allocation,
>                                          gpointer data G_GNUC_UNUSED)
>  {
> +    GtkRequisition preferred;
> +
> +    /* ignore all allocations before the widget gets mapped to screen since
> we
> +     * only want to trigger guest resizing due to user actions
> +     */
> +    if (!gtk_widget_get_mapped(GTK_WIDGET(self)))
> +        return;
> +
> +    /* when the window gets resized due to a change in zoom level, we don't
> want
> +     * to re-size the guest display.  So if we get an allocation event that
> +     * resizes the window to the size it already wants to be (based on
> desktop
> +     * size and zoom level), just return early
> +     */
> +    gtk_widget_get_preferred_size(GTK_WIDGET(self), NULL, &preferred);
> +    if (preferred.width == allocation->width
> +        && preferred.height == allocation->height) {
> +        return;
> +    }
> +
>      if (self->priv->auto_resize != AUTO_RESIZE_NEVER)
>          virt_viewer_display_spice_monitor_geometry_changed(self);
>  
> --
> 1.8.5.3
> 
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
> 




More information about the virt-tools-list mailing list