screen freezes and black artefacts on Windows VNC server

[calestyo]

Hey.

Describe the bug
I've experience this since quite a while (this is now all on TigerVNC server 1.13.1 64 bit on Windows 10).

It began a while ago, when typically right after connection to the VNC server, the image in the client froze and black rectangular artefacts appeared like in (bottom):

Though usually there were much more (this is a recent image, where this particular thing with the black rectangles happens only rarely).

This could have happened typically at any state of Windows (e.g. when it was not yet logged on, but also when it was already logged on). It typically occurred right when connecting to the VNC server, but sometimes it also happened spuriously when the connection was already working for quite a while.

What's much more common meanwhile is a bit different:

There are no black rectangles (though sometimes even this still occurs), but the image simply freezes. This may also happen at some vertical line when the screen was just redrawn. Like in:

That's the background image right after Windows booted (no password prompt yet), I move the mouse, windows wants to go on to the login screen an would paint a blue background, but halfway through the VNC image freezes.

This nearly always happens only at Windows login (I cannot even remember if it ever happened when the connection was already working for a while, perhaps sometimes).

Interestingly, at least this issue (without the black rectangles) can always be cured, by changing the quality from e.g. good to medium or from medium to poor in the client.

Then the image unfreezes and things move on. It even seems that any keyboard input that was made while the image was frozen, actually made it to the server.

It very often happens at login, where Windows make some strange effect on the transparency of the background,... as if it cycles through various transparency levels or so. Maybe this is related.

Here's an image where it froze, when doing that "cycling".

Client (please complete the following information):

• OS: Debian unstable
• VNC client: Remmina
• VNC client version: 1.4.35
• Client downloaded from: Debian

Server (please complete the following information):

• OS: Windows 10
• VNC server: TigerVNC
• VNC server version: 1.13.1 64 bit
• Server downloaded from: sf.net page
• Server was started using: Windows service

I know, Windows server is unmaintained, but perhaps someone has an idea.

Thanks,
Chris.

[CendioOssman]

Not something we are aware of, unfortunately. It sounds like it stalls the updates for some reason.

Does the refresh from the F8 menu help?

And does the issue happen with our client?

[calestyo]

Not something we are aware of, unfortunately. It sounds like it stalls the updates for some reason.

Does the refresh from the F8 menu help?

Indeed that does help.

And does the issue happen with our client?

It seems it does not. Shall I open the ticket at remmia?

Cheers,
Chris.

[CendioOssman]

It seems it does not. Shall I open the ticket at remmia?

That could be helpful. I don't know when anyone will have time to look at it from our end. Doubly so with it being WinVNC. :/

It might also be useful to test some more viewers, to try to determine if it breaks with every viewer other than ours, or just Remmina.

[calestyo]

FYI: https://gitlab.com/Remmina/Remmina/-/issues/3121

It also doesn't seem to happen with TightVNC's viewer (not sure how close their codebase is with yours).

[CendioOssman]

They are fairly different. Which suggests the issue is indeed with Remmina, since both TigerVNC and TightVNC clients work.

Let's see what they can find.

[calestyo]

Seems one one of the developers there was already able to reproduce parts of the issue. Not sure whether we should keep this one here open meanwhile?!

[CendioOssman]

Let's give them a few days to confirm if the issue is truly in Remmina.