still need review on this. haven't noticed any regressions in the past week.
----- Original Message -----
> From: "Jonathon Jongsma" <jjongsma@xxxxxxxxxx>
> To: virt-tools-list@xxxxxxxxxx
> Sent: Thursday, March 6, 2014 4:15:25 PM
> Subject: [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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
