Description of problem:
Between gtk-vnc-0.4.1-6.fc14.1 and gtk-vnc-0.4.2-1.fc14, something changed to cause text scrolling to become extremely slow.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Start a qemu-kvm Fedora (any version) guest using virt-manager
2.Inside that guest, open a terminal window.
3.Inside the terminal window, 'ls -1 /etc'
Is quick, as before.
(In reply to comment #0)
> Description of problem:
> Between gtk-vnc-0.4.1-6.fc14.1 and gtk-vnc-0.4.2-1.fc14, something changed to
> cause text scrolling to become extremely slow.
> Version-Release number of selected component (if applicable):
> How reproducible:
> Steps to Reproduce:
> 1.Start a qemu-kvm Fedora (any version) guest using virt-manager
> 2.Inside that guest, open a terminal window.
> 3.Inside the terminal window, 'ls -1 /etc'
> Actual results:
> Takes *ages*
> Expected results:
> Is quick, as before.
This bug also affects general video display for Windows XP VMs. With 0.4.2-1, my XP VM is basically unusable because the screen repaints so slowly. If I downgrade to 0.4.1-6, everything is fine.
Can you please capture a trace with both the new & old versions of gtk-vnc using
virt-viewer --gtk-vnc-debug $GUESTNAME
This should show me if there is any difference in data being sent to/from the server
I am seeing some difference between the two packages (0.4.1 and 0.4.2)
although it is not very pronounced. But my laptop is very fast ...
I have a guest with a gnome terminal open, and in the gnome terminal
I run "while true; do find /; done" so that the terminal is constantly
With 0.4.1 I am able to grab the window and move it around, also access
the gnome menus.
With 0.4.2 the mouse is much more laggy, to the point where it is very
hard to grab the window or access the menus.
I will supply the debug data in follow-up attachments.
Created attachment 463454 [details]
Debugging trace from gtk-vnc 0.4.1 (non-laggy version)
Created attachment 463455 [details]
Debugging trace from gtk-vnc 0.4.2 (laggy version)
The traces show the same colour depth, and same framebuffer encoding (tight) in use in both cases. So the problem is likely the client side rendering code which changed between these releases.
I had the feeling while watching text get rendered very slowly that perhaps text updates were being sent as a large number of very small rectangle updates rather than one large one, but I didn't manage to verify that.
In GTK-VNC 0.4.1, we had an GdkImage on the client and a GdkPixmap on the server/ Incoming FB updates render to the image, then sync the changed region in the image to the server side pixmap. Then we render the pixmap to the window, applying scaling & offsetting.
In GTK-VNC 0.4.2, we removed the server side pixmap, and render just the changed image region directly to the window, applying scaling & offseting at the same time. With the clipping we do, this shouldn't have impacted performance significantly.
My theory though is that when scaling & offsetting is used during rendering, cairo is being forced to copy the entire source image, rather than just the clipped region.
This scratch build introduces a server side cairo image surface to cache data, in a similar way to the manner in which we used Pixmaps. I can't reproduce the performance problem in the first place though, so I need someone else to confirm whether this makes any difference to performance.
The scratch package fixes the problem for me.
For me, it's better than before, but still slower than 0.4.1
I tried the packages from koji with my WinXP VM. There's no obvious difference for me between these and 0.4.1.
gtk-vnc-0.4.2-3.fc14 has been submitted as an update for Fedora 14.
gtk-vnc-0.4.2-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update gtk-vnc'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gtk-vnc-0.4.2-3.fc14
gtk-vnc-0.4.2-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
daniel, joel: I think there's a separate bug which makes VMs respond more and more sluggishly over time, which may not have been fixed yet. I'm going to report that shortly. With the new build the text output issue sure looks fixed to me, it's much much faster, but the general sluggish response (getting more sluggish over time) bug remains.
> I think there's a separate bug which makes VMs respond more and
more sluggishly over time,
Adam, now that you mention it, I think you're right. Can you add me to the CC list for that bug? (Or post the bug number here?)
Same here -- I've noticed it especially when there are several VMs running.
yep, it's https://bugzilla.redhat.com/show_bug.cgi?id=657847 - I've confirmed that downgrading gtk-vnc still makes it better, so it's clearly a separate regression in gtk-vnc. please follow up in that bug :)