#1241 Win 8 desktop image is scrambled on some systems in 2.7.1

None
closed-fixed
5
2013-06-07
2013-05-06
No

The problem is TightVNC doesn't take the stride field of the autoMapSurface into account when copying data to m_targetFB in Win8DeskDuplicationThread::processDirtyRects(). It must call autoMapSurface.getStride() and make sure Framebuffer::copyFrom() respects the stride when copying the data.

This doesn't happen at all screen resolutions because sometimes the stride is 0. The most prevelant resolution that we've see this is on 1366x768 - thats when the stride field is usually non-zero.

Related

Bugs: #1241

Discussion

  • Haseeb Abdul Qadir

    • summary: Win 8 desktop image is scrambled on some systems --> Win 8 desktop image is scrambled on some systems in 2.7.1
     
  • Haseeb Abdul Qadir

    Also - this happens on actual hardware. I wasn't able to reproduce this on a VMWare Fusion VM.

     
  • console_cc

    console_cc - 2013-05-26

    I also experience this problem with a server on Windows 8 64bit. I tried to uninstall the mirror driver, but doesn't seem to be related.

     
  • Anonymous - 2013-06-07

    Please, test version 2.7.7 for this error.

     
  • console_cc

    console_cc - 2013-06-07

    2.7.7 fixed this for me.

    Server: Windows 8 64bit
    Client: iTeleport on iOS and OS X

     
  • Anonymous - 2013-06-07
    • status: open --> closed-fixed
    • assigned_to: alex-tightvnc
    • Group: -->
     
  • Anonymous - 2013-06-07

    Fixed in 2.7.7.

     
  • Haseeb Abdul Qadir

    Confirmed fixed with Jump Desktop 5.5.

    On 2013-06-07, at 6:53 AM, alex-tightvnc alex-tightvnc@users.sf.net wrote:

    Fixed in 2.7.7.

    [bugs:#1241] Win 8 desktop image is scrambled on some systems in 2.7.1

    Status: closed-fixed
    Labels: Win32 Version
    Created: Mon May 06, 2013 01:16 PM UTC by Haseeb Abdul Qadir
    Last Updated: Fri Jun 07, 2013 10:52 AM UTC
    Owner: alex-tightvnc

    The problem is TightVNC doesn't take the stride field of the autoMapSurface into account when copying data to m_targetFB in Win8DeskDuplicationThread::processDirtyRects(). It must call autoMapSurface.getStride() and make sure Framebuffer::copyFrom() respects the stride when copying the data.

    This doesn't happen at all screen resolutions because sometimes the stride is 0. The most prevelant resolution that we've see this is on 1366x768 - thats when the stride field is usually non-zero.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/vnc-tight/bugs/1241/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #1241


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks