Sure can - this will be good to do anyway, because Yu is “needing more information” on the bug report 
On a sidenote, using Picture.Save, also saves the 1pixel offset into the saved image (when using odd numbered dimensions that is). I’ve been trying everything to see where/when the issue exists.
Will be making a video later this evening, but I did use Spy++ in lieu of ollydebug and did note the windows messages firing, see the log that was uploaded. And the messages did fire between moving the window between monitors from scaled to non-scaled.
Unrelated I believe to the current issue, but found another…
You’ll note I did update the demo to invoke a bunch of windows APIs to ensure things are actually working correctly moment-by-moment (using a timer to poll metrics). Number of monitors updates correctly as well as screen dimensions upon moving the application between displays and across systems. The only issue I did note is, the scale x & scale y do not update while moving the application between different scaled monitors, and always remains with the start-up scaling preserved. This should change between scaled monitors attached to the same system, but does not.
At this time I do not believe Xojo Applications are fully DPI aware, as in version 2 of Windows DPI awareness, they (Microsoft) added Per-Monitor-DPI Awareness, and this does not seem to be functioning…
Odd, I see that change moving from a 100% screen to a 125% screen.
Ok, after a lot of testing I found the problem and it looks like this is the problem from 2017!!!
<https://xojo.com/issue/46743>
Controls aren’t being sized correctly for their scaling causing the internals of the width being reported incorrectly compared to what is physically shown on the screen, this only happens when their locking flags are set.
If you move a 4 wide canvas from 100% to 175% it should change from 4 to 7, however it changes to 11 for some reason. This causes render calculations to fail as the reported width is now 6 instead of 7 (another bug) but the control is physically 11 wide which is why your demo isn’t rendering all the way to the edge.
Of course, this all works ok if the scaling isn’t changed which is probably why it hasn’t been fixed. Such a waste of time for something that been reported and not fixed 
Holy Cow Julian - Great work tracking this down! I have my video uploaded to share with Yu, and will add your info to the current bug report today if you haven’t already - tying it to the old bug report. I believe you’ve hit the nail on the head for this! Just went pixel by pixel and confirmed your findings are 100% accurate. Thanks for all your help dabbling with the canvas to track this bug down…again
Much of this behavior depends on the DPI awareness settings. See Setting the default DPI awareness for a process (Windows) - Win32 apps | Microsoft Docs
Are any of you doing any manifest hacking?
Do you have the application set to build for Windows 10 on the Advanced Build settings?
Xojo handles all that.
No, all these tests were done with 2021r3.1 “out of the box”
No changes were made to the default project’s settings after a new install of 2021r3.1
It might be interesting to toggle off the Windows 10 settings and see if that changes anything.
No change.