**Screenshot: In screenshot, offset has been set to 0 and borderwidth to 1, from the supplied example. I changed the right and bottom border colors to orange and yellow for contrast against the blue background to evidence the 1pixel offset showing for right and bottom sides of the canvas.
Hopefully we can track down what’s causing this issue. 
Can you post that as a png as its been jpg’d into a potato?
Do you have some external scaling going on because your window is around 782 pixels wide when it should be 600 and your image looks all fuzzy as do your 1 pixel wide lines.
Since .Width and .Height are doubles in the drawing commands on Graphics you may wanna round them (up).
There’s no fractional maths in the example, I’m trying to work out how Matthew is getting a blurry image and blurry lines.
If you click the image to enlarge, and view the full-size does it appear blurry? Seems to appear fine on mobile device and desktop here.
For the main issue. Fired up my mac and Ubuntu desktop and noted the issue does not happen on either - So this is definitely only a Windows-only issue occurring.
**If I save the Canvas image to png on Windows (Picture.Save), the offset still shows - was testing to see if the save method somehow corrected/or clipped the “additional” pixels not accounted for. It did not 
Trying a little bit of everything to see what works and doesn’t.
Derk - I thought the same previous and tested to ensure there were no “half-pixels” being accounted for on the HR systems…unfortunately, all pixels are accounted for
Don’t know couldn’t say how xojo handles the doubles there.
AHA - Getting somewhere - so in the example, the canvas has “odd” dimensions with 405 and 311 for width and height. If I set the dimensions to even numbers (404 or 406 & 310 or 312, the issue instantly disappears on windows, and the offset is not needed…
Looks like this possibly is a Xojo & High Resolution issue with “odd numbered” dimensions. Removing “Hi-Res Support” completely eliminates the issue on Windows, regardless of the canvas dimensions…
odd…
Quick follow-up - So, If the dimensions of the canvas are locked and the window resized pixel by pixel - the issue appears and disappears as the canvas dimension go from odd to even numbers. So the issue would still persist if resizing invokes odd-numbered dimensions.
Have added details to the bug report for Yu.
This is what I’d expect in a scaled screen which yours seems to look like as the screenshots you’re posting aren’t crisp, how thought, I don’t know.
Both of these are zoomed to 400%, mine is on the right, yours is on the left 133% bigger and blurry:
Yours has thicker top line due to the scaling, mine doesn’t as its 100% native, without seeing your setup its hard to say why, but this isn’t a bug, you have to account for scaling when drawing as 1 pixel isn’t 1 pixel when scaled.
Even your Display > Scale and layout window is bigger, so I don’t think a xojo issue.
Are you running windows in a vm ?
Try viewing screenshot not loaded into the forum… see
https://www.osblueflame.com/screenshots/
Any additional screenshots I can post in there, seems the forum is jacking up images as well
Ok finally, that is the first one I’ve seen that is at the correct scaling, I assume that you’re running this with the offset of 1 because it looks exactly like mine does now when I run with the offset of 1
I’ve tested on my development machine laptop, and 2 brand new laptops straight out of the box of different brands. All 3 show the issue and scaling is 100% so it’s really odd. Tested on desktop machine also with a standard HD monitor also. Lol I know it’s a pain trying to track down
Offset set to 0 to make the issue appear. If I set to 1, the pixels are accounted for. So yours set with 0, displays as mine shows set to 1. Super odd
What are the model numbers of the laptops?
Laptop - Dell XPS 15 (2020 model)
Laptop - ASUS Q504UA
Laptop - LG Gram 17 (2021 model)
Desktop - HP Omen 30L
**Only LG Gram 17 is Windows 11 by the way - have not updated the Omen as other software we develop is not quite windows 11 ready (a dot net piece of software - client systems don’t all support windows 11 features yet)
Can you upload the image you posted here Replacement--Rectangle: TopLeftColor/BottomRightColor - #23 by Matthew_Combatti to that site so I can see the original?
Sorry for delay - had Zoom meeting I’ve uploaded the screenshot to the online directory. Let me know if you need anything else or have any ideas. Later I’ll be attempting to hook into the window using OllyDebug to see if/when the WM_DPICHANGED windows message is being fired. Technically, if you have more than one monitor (lets say the 2nd will be scaled and the primary is not), if the application is truly DPI-aware, the Windows WM_DPICHANGED message should be fired simply by moving the window from one monitor display to the next; At least, that’s how DPI-aware apps should work anyway. I’m going to test this later to see if the application is “truly DPI-aware” (1PM here now - will be around 5:30ish by time I can setup other monitors to test this out).
Makes no sense at all that a line can somehow shift up by one pixel given how far down the screen it is, which is essentially what is happening.
Can you do a little video going over the code and running the project? Maybe it’ll shed some light on a missing issue.
