Unable to use region editor over RDP

[mmmmmtasty]

Hi

There are a few issues that are standing in the way of me (and my colleagues) making proper use of this tool related to how poorly it works over RDP (Microsoft's native Remote Desktop Protocol) currently. They totally seem like fixable issues though and will also benefit anyone else using remoting protocols. I'm creating separate issues for them to help tracking.

Describe the bug
  -  When connected to your workstation over the RDP protocol, you cannot open the regions tool as the Desktop Window Manager goes to 100% CPU usage until MaxTo finally crashes, quicker if you try and interact with it. I think what may help here is if I could turn off the special transparency/blurring effect that it uses. If it could instead use a single colour half transparent overlay, or even have the option for disabling any transparency at all then I suspect it would work just fine.

• The settings screen also has transparency on the left hand side, if we could disable that as well it would speed up general usage of the application.   - I only have 4k monitors in the house, so I don't know if it also happens with lower resolutions at this point.

To Reproduce
 - Install MaxTo on a workstation - Connect to that workstation using Microsoft's Remote Desktop Client from a Windows workstation with more than one monitor attached.
Double click the system tray icon and watch MaxTo appear on the monitors very, very slowly and crash if you interact with it
 - Use "maxto regions apply"

Expected behavior
The region editor opens quickly and allows me to interact with it to create a new layout.

System information:

• Windows version: 1607 LTSB, also happens on 1909 SAC though.
• MaxTo version: 2.1.5

Additional context

• This was tested with 1, 2 and 4 4k monitors attached and the behaviour was the same each time. It was almost usable with just one monitor attached but still crashed.
• I am creating regions by editing the config.json file right now, it works but it isn't ideal

[github-actions]

Thank you for creating your first issue. We will get to it as soon as possible. This is an automated message designed to manage your expectations. We will most likely respond to your message during Norwegian business hours. If you should think of any additional information, please feel free to add it as a comment. If you are reporting a bug or incompatibility, make sure you include the versions of MaxTo, Windows and any incompatible program.

[vegardlarsen]

Thank you for writing. I am aware of the general performance issues with these windows, and they are not specific to RDP sessions (but may very well be worse over RDP). I am assuming that DWM crashes on the remote machine, not the RDP client machine, when this happens?

Version 1607 LTSB is end-of-servicing, but I will attempt to investigate this on 1909 and higher.

Can you please attach the log files from around the time the crash happens?

[mmmmmtasty]

Hi, I don't see DWM crash, I see MaxTo itself go to "Not Responding" after I click on it and get the offer of closing it. DWM is sat at 100% CPU until that happens though. Even waiting forever in the hope that the region editor loads properly doesn't result in a window that I can actually interact with.

You are correct though that everything I am describing is happening on the remote workstation, the local workstation works just fine.

I've attached a log file from 1607 LTSB, it is still in extended support for another almost 6 years so perhaps would still be some value there. The normal logs contained nothing informative and were the same on both OSes, so I put the logging level to debug. The logs still don't say anything useful though, everything just runs extremely slowly while no lines are being written to the log file. When I click on the region editor and then Windows says the program is not responding, and I choose to close the application - only then does the "Pipe is broken" exception that you see in the log happen. Are there any other log files I can fish out that would be helpful for you?

This does scale with screen size. If I open a window at 1600x1200 then the region editor is usable but very slow. With 1x4k it is sometimes responsive, sometimes not. With 4 monitors it is completely unusable.

maxto20210104.sanitised.1607.log

[vegardlarsen]

This seems absolutely like the same issue as #684, however yours is so slow that it could be possible to deduct some information from it. Performance inversely correlated with the total resolution, and the fact that DWM pegs the CPU, strongly indicates that something is wrong with our DWM implementation. I have a suspicion here; what is the exact build number when you run winver?

My suspicion here is that acrylic support was introduced in Windows 10.0.17134, and we may be requesting an invalid state from Windows 10 when the version is less than that. That's one hypothesis at least.

[mmmmmtasty]

The issue that you link to is using 20H2 though which is as new as it comes. I do also see slow interactions when clicking around in the settings app, when I drag it around it is quick, but only because I render only the outline of the window when dragging for speed improvements.

The version number is: 10.0.14393

This does still happen on 1909 though (marginally better performance I would have to guess, but also insanely slow). The build number of that OS is 10.0.18363

[vegardlarsen]

After some experimentation, I can reproduce this in a virtual machine. Key points are that I:

• Connect through RDP
• Use all my monitors (one 4K and one ultrawide, so large total resolution)
• DWM doesn't lock completely, but it takes quite a while (multiple seconds) to display these windows.

I am trying to investigate in more detail.

[vegardlarsen]

I have found that this is strongly related to the background acrylic we are applying, and removing the effect will cause this problem to be almost completely mitigated. As of version 2.2.0, we remove the acrylic effect on all of the MaxTo windows, and instead will use battleship gray where the acrylic effect used to be. When resizing regions, the gray will become partially transparent allowing you to see the window border underneath, which is a nice bonus.

All in all, MaxTo will look less designed, but will perform quite a bit faster.