#1227 Corruption, artifacts with Viewer 2.6.4 on WinXP 32bit


I recently uninstalled TightVNC 1.3.10 from my Windows XP SP3 32bit machine and installed TightVNC 2.6.4.

Unfortunately the new TightVNC Viewer seems to have painting issues.
Random parts of the image are being painted without color.
Have a look at the attached JPEG image file "tightvnc.viewer.2.6.4.winxp.sp3.artifacts.jpg".

It does not seem to matter which kind of VNC server I connect to, the problem persists. I am experiencing this issue with the following kinds of servers:
- x11vnc on a Debian Squeeze machine (x11vnc: 0.9.10 lastmod: 2010-04-28)
- TightVNC 1.3.10 Server on another Windows XP SP3 32bit machine
- x11vnc on an Ubuntu 12.04 LTS machine (x11vnc: 0.9.12 lastmod: 2010-09-09)

This, and the fact that the problems started to occur once I switched to the new TightVNC Viewer, makes me assume that the viewer side is to blame here.
I have tried the TightVNC Java viewer 2.6.2 and it does not exhibit these problems.
The painting errors persist when I change the viewer's scaling of the displayed picture.

If it is any help, the WinXP machine the affected viewer runs on is thoroughly patched and uses an ATI HD 5000 graphics card running with ATI Catalyst 13.1. It too is running a TightVNC server at all times and has the Mirage Driver installed.


  • eomanis

    • labels: --> Win32 Version
  • eomanis

    • summary: Corruption, artifacts with Viewer on WinXP 32bit --> Corruption, artifacts with Viewer 2.6.4 on WinXP 32bit
  • eomanis

    edit: Exchanged the JPEG file for a PNG file, which is smaller than the JPEG anyway

  • Hello eomanis.

    It's weird issue.
    You may set logging level to 9 in Configuration of Viewer and send log?

    Problem with painting occur continuously or from time to time?
    You may change encoding in options?

    • status: open --> open-fixed
  • eomanis

    Hello knst-tightvnc,

    I can confirm that this bug has been fixed in the pre-release version 2.6.94 32bit.
    Awesome, thanks a lot.

    And yes, the viewer option "Preferred encoding" was set to "Tight".
    I didn't test whether the affected version 2.6.4 showed this bug with a different encoding setting, though.