Hi Daniel, > -----Original Message----- > From: Daniel P. Berrangé <berra...@redhat.com> > Sent: Thursday, March 7, 2024 10:01 AM > To: Kim, Dongwon <dongwon....@intel.com> > Cc: Marc-André Lureau <marcandre.lur...@gmail.com>; qemu- > de...@nongnu.org > Subject: Re: [PATCH 1/3] ui/gtk: skip drawing guest scanout when associated > VC is invisible > > On Thu, Mar 07, 2024 at 05:53:24PM +0000, Kim, Dongwon wrote: > > Hi Daniel, > > > > > -----Original Message----- > > > From: Daniel P. Berrangé <berra...@redhat.com> > > > Sent: Thursday, March 7, 2024 1:46 AM > > > To: Kim, Dongwon <dongwon....@intel.com> > > > Cc: Marc-André Lureau <marcandre.lur...@gmail.com>; qemu- > > > de...@nongnu.org > > > Subject: Re: [PATCH 1/3] ui/gtk: skip drawing guest scanout when > > > associated VC is invisible > > > > > > On Thu, Feb 01, 2024 at 06:48:58PM +0000, Kim, Dongwon wrote: > > > > Hi Marc-André, > > > > > > > > Thanks for your feedback. Yes, you are right, rendering doesn't > > > > stop on Ubuntu system as it has preview even after the window is > > > > minimized. But > > > this is not always the case. > > > > Some simple windows managers don't have this preview (thumbnail) > > > > feature and this visible flag is not toggled. And the rendering > > > > stops right away there when the window is minimized. > > > > > > This makes me pretty uncomfortable. This is proposing changing QEMU > > > behaviour to workaround a problem whose behaviour varies based on > > > what 3rd party software QEMU is running on > > > > > > What you say "window managers" are you referring to a traditional > > > X11 based host display only, or does the problem also exist on > > > modern Wayland host display ? > > > > [Kim, Dongwon] I didn't mean anything about the compositor/display > > server itself. And I am not sure about the general behavior of Wayland > > compositors but the point here is the rendering while the app is being > > iconized (minimized) is not always the case. For example, ICE-WM on > > Yocto Linux doesn't have any preview for the iconized or minimized > > applications, which means all drawing activities on the minimized app > > are paused. This is the problem in case blob scanout is used with > > virtio-gpu on the guest because the guest won't receive the response > > for the frame submission until the frame is fully rendered on the > > host. This is causing timeout and further issue on the display > > pipeline in virtio-gpu driver in the guest. > > I guess I'm wondering why we should consider this a bug in QEMU rather than > a bug in either the toolkit or host rendering stack ? > > Lets say there was no guest OS here, just a regular host app issuing drawing > requests that were equivalent to the workload the guest is issuing. If that > applications' execution got blocked because its drawing requests are not > getting processed when iconified, I'd be inclined to call it a bug. > > Or are we perhaps handling drawing in the wrong way in QEMU ? [Kim, Dongwon] Hmm.. Yeah that is a good point.. If non-rendering workload is blocked in the same way, that would be a problem. > > If the problem is with drawing to a iconified windows, is there an > intermediate > target buffer we should be drawing to, instead of directly to the window. > There > must be some supported way to have drawing requests fully processed in the > background indepent of having a visible window, surely ? [Kim, Dongwon] I will check what other options that don't look like WAs are available.
> > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
