Bug 657542 - Extremely slow when text is moved
Summary: Extremely slow when text is moved
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk-vnc
Version: 14
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Daniel Berrangé
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-26 12:21 UTC by Tim Waugh
Modified: 2010-12-03 13:46 UTC (History)
8 users (show)

Fixed In Version: gtk-vnc-0.4.2-3.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-02 19:08:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Debugging trace from gtk-vnc 0.4.1 (non-laggy version) (1.57 MB, application/x-xz)
2010-11-29 10:06 UTC, Richard W.M. Jones
no flags Details
Debugging trace from gtk-vnc 0.4.2 (laggy version) (664.80 KB, application/x-xz)
2010-11-29 10:07 UTC, Richard W.M. Jones
no flags Details

Description Tim Waugh 2010-11-26 12:21:46 UTC
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):
gtk-vnc-0.4.2-1.fc14

How reproducible:
100%

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.

Comment 1 Adel Gadllah 2010-11-26 13:17:38 UTC
(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):
> gtk-vnc-0.4.2-1.fc14
> 
> How reproducible:
> 100%
> 
> 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.

Same here.

Comment 2 Joel Uckelman 2010-11-28 23:56:51 UTC
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.

Comment 3 Daniel Berrangé 2010-11-29 09:50:37 UTC
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

Comment 4 Richard W.M. Jones 2010-11-29 10:02:34 UTC
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
scrolling.

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.

Comment 5 Richard W.M. Jones 2010-11-29 10:06:57 UTC
Created attachment 463454 [details]
Debugging trace from gtk-vnc 0.4.1 (non-laggy version)

Comment 6 Richard W.M. Jones 2010-11-29 10:07:45 UTC
Created attachment 463455 [details]
Debugging trace from gtk-vnc 0.4.2 (laggy version)

Comment 7 Daniel Berrangé 2010-11-29 11:17:23 UTC
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.

Comment 8 Tim Waugh 2010-11-29 12:00:12 UTC
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.

Comment 9 Daniel Berrangé 2010-11-29 15:18:36 UTC
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.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2632024

Comment 10 Richard W.M. Jones 2010-11-29 15:37:27 UTC
The scratch package fixes the problem for me.

Comment 11 Daniel B 2010-11-29 15:42:53 UTC
For me, it's better than before, but still slower than 0.4.1

Regards, Daniel

Comment 12 Joel Uckelman 2010-11-29 16:23:22 UTC
I tried the packages from koji with my WinXP VM. There's no obvious difference for me between these and 0.4.1.

Comment 13 Fedora Update System 2010-11-29 16:58:22 UTC
gtk-vnc-0.4.2-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gtk-vnc-0.4.2-3.fc14

Comment 14 Fedora Update System 2010-11-29 21:27:59 UTC
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

Comment 15 Fedora Update System 2010-12-02 19:08:25 UTC
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.

Comment 16 Adam Williamson 2010-12-02 20:21:08 UTC
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.

Comment 17 Joel Uckelman 2010-12-03 10:47:46 UTC
>  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?)

Comment 18 Tim Waugh 2010-12-03 11:49:24 UTC
Same here -- I've noticed it especially when there are several VMs running.

Comment 19 Adam Williamson 2010-12-03 13:46:09 UTC
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 :)


Note You need to log in before you can comment on or make changes to this bug.