This is effectively full screen on my 2nd (2K) monitor. When I set screen mode id:i:2 (or w x h to 384-x2028), full screen on my 4K monitor, the problem starts
2 What happens is when I start my dbf browsing tool dbv (which is still based on the OLD VO databrowser) it takes 7-10 seconds to come up with the first screen and any movement in the table takes seconds. You see a slight distortion in the screen before it rebuilds with the refreshed data.
3 ADS Data Architect has exactly the same problem
4 Our program itself with the same data (dbf's) is fast but all browsers are bBrowser based
5 With HD only in the RDP. 2+3 are instantly, also on the 4K monitor (which uses 1/4 of the screen of course)
6 They have updates drivers for video etc. without success.
Sorry, I can't even pretend to understand the full details of what you are experiencing.
However, I think at the root the problem lies with the time taken to re-paint the screen when you have vastly different screen resolutions.
This is just one of the problems Net Core is designed to overcome.
VS 2019 has only just (a couple of weeks) been upgraded to address Net Core 3.
Transferring code from .Net Framework to .Net Core does not appear to me to be the easiest of tasks.
But on the basis of the rate at which MS is upgrading things, it won't be too long before some sort of tooling to aid transformation, Framework to Core becomes available.
Thank you for your reply. It is surely a combination of things. The very old VO databrowser in my dbf tool and -apparently- some outdated technique in ADS' Data Architect versus bBrowser, in which the same browsing (from within my program) goes smoothly. But also: on none of the other servers I access via RDP this problem occurs. Only on this brand new server.
If the app works okay locally on the server and really slow over RDP, then this is an RDP problem. The app may be doing squillions of screen updates, but RDP is quite capable of handling that if the bandwidth is right.