Delay while typing in Visual Studio Code

Forums / NoMachine Terminal Server Products / Delay while typing in Visual Studio Code

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #20614
    Avatarrichterger
    Participant

    Hi,

    we are currently testing NoMachine Terminal Server. It works fine, but we have issues when running Visual Studio Code.

    Client runs on Windows, applications run as standalone applications (no full Linux desktop).

    First the screen display was had a very low contrast, so we aren’t able to read much. By setting

    ProxyExtraOptions pack=16m-png

    in node.cfg this problem could be solved. The question is, is there any better way to do this?

    The problem we face now is, that while typing every key is delayed, so you can’t really work with the application. It seems that every keystroke takes about one second, so if you type more than one key, you get a huge delay.

    Any idea how to solve this?

    Working with xfce4-terminal works perfectly. There was no need to set the ProxyExtraOptions and also typing is fine.

    We have installed “nomachine-terminal-server-evaluation_6.3.6_2_amd64.deb” running on Ubuntu 18.04.1

    Client is 6.3.6_1 on Windows 10

    Connection is via ssh

    Thanks & Regards

    Gerald

    #20656
    Avatargraywolf
    Moderator

    Could you provide a screenshot showing the image quality that made you switch to ProxyExtraOptions pack=16m-png?
    It is possible that tweak also affected performace. Do you experience the same keyboard delays if you removed it?
    Is AgentX11VectorGraphics to its default value (AgentX11VectorGraphics 1)?

    #20804
    Avatarrichterger
    Participant

    AgentX11VectorGraphics is commented out like this:

    #AgentX11VectorGraphics 1

    If I switch back to the state without ProxyExtraOptions the typing speed is ok again, but contrast is very low. Attached is an example how it look with NX default settings and how it look on Windows (when setting¬† ProxyExtraOptions pack=16m-png¬† you get the same result as on the windows screenshot, with NX on Linux. I just can’t switch it back at the moment).

    Thanks & Regards

    Gerald

     

    #20885
    Avatargraywolf
    Moderator

    Would you try to change this in node.cfg:

    DisplayServerExtraOptions "-extension MIT-SHM"

    It affects the way text and images are encoded for remote transfer.

    #20945
    Avatarrichterger
    Participant

    Unfortunately setting this extension makes no difference.

    Just in case it makes a difference:

    I am running a “user defined session” starting only a xfce4-terminal in seamless mode and from the cmdline I am starting the visual studio code.

    Then both are running seamless on the windows desktop. That works very well, only colors and fonts not come through as expected and this is really a show stopper for using it in our development team.

    Thanks & Regards

    Gerald

     

     

    #21032
    Avatargraywolf
    Moderator

    I’ve observed VSC behavior and concluded it does not benefit of X11 vector graphics. It looks rendering the content of its user interface as images, text included.

    The only way to handle this would be using PNG-encoded images as you’ve done. As you noticed, that would impact performance. Such impact could be reduced choosing a lower quality for png (adding a suffix to 16m-png string, e.g. 16m-png-5 would fix quality to level 5, with possible level ranging from 1 up to 9).

    #21204
    Avatarrichterger
    Participant

    I tried 16m-png-5 and it behaves better, but I still have a delay. Is there some documentation/list which values are allowed, so I can play around which value works best?

    Second question, when will a change of this value become active? Only when I start a fresh session oder is it enough to disconnect and reconnect to an existing session?

    Last question, is it possible to change/set this value in the client, so we can have different setting for different users, depending on their connection?

    Thanks & Regards

    Gerald

     

    #21220
    Avatargraywolf
    Moderator

    Gerald, I made a mistake, sorry. The algorithm encoding images to PNG ignores the quality index. Playing with that value can’t lead to any improvement.

    There are some other lossless methods you could pass to the “pack=” option. All they set fast-encoding algorithms for images but with less regard to the bandwidth usage. Please try them so we can understand whether the problem is actually due to bandwidth usage rather than encoding speed.

    They are
    pack=bitmap
    pack=rgb
    pack=rle

    “bitmap” doesn’t compress the image at all, so the bandwidth usage will be huge.

    Such options can’t be set in the client, btw you can create customized per-user configuration files on server side: just copy node.cfg to <username>.node.cfg and do your changes there.

    #21525
    Avatarrichterger
    Participant

    I tested the different variations: bitmap and rle are totally slow. It takes about 10 sec to initially show the application. rle and 16m-png are more or less the same. Everything looks good, but you have a small delay while typing, but it’s too high to comfortably work. With 16m-jpeg working with the application is fine and without any delay, but the display has low contrast, as described above.

    So using png but with less bandwidth needs would be ideal. Is there any way to reduce the size of tranferred data, but with a looseless compression? I would expect, that reducing the number of colors to 64K or even 256 could help and would be fine for this kind of usage.

    What settings are available for pack= . If I know what can be used, I just try them out.

    Thanks & Regards

    Gerald

     

     

    #21535
    Avatargraywolf
    Moderator

    256k-png would be what you are looking for, but that 256k prefix is a legacy and actually ignored.

    There is no way to change the number of colors in the current version of NoMachine. All the test we did at our labs showed that any gain in terms of reduced bandwitdh was little and not worth the quality degradation.

Viewing 10 posts - 1 through 10 (of 10 total)

This topic was marked as solved, you can't post.