Subtle drawing bug(?) -> fillRect (integer version) scaled


#1

the integer version of fillRect -> Graphics::fillRect (int x, int y, int width, int height)
aligns the coordinates to pixels, even when its in a context which is scaled.
The is inconsistent with other integer drawing functions like drawRect, so im pretty sure this is a bug.
(checked on windows)

You can see this very easily when a TreeView is scaled, which uses the integer version of fillRect and drawRect to draw the + - box

(the right version uses the float version of fillRect)


Issue with pixel-accurate fillRect
Graphics::fillAll bug
#2

TBH I’d rather fix that by changing the TreeView code than the rendering code, as I would expect to see all kind of grumbling about other subtle drawing “errors” if I did that! Will do that now, and might have a quick search for other places where the int version could be swapped for the float one…


#3

Yes okay!
But on the other hand, the usual high-dpi rendering is done in OSX implicit through CoreGraphics, on Windows its done via transformations, so the same physical pixel sized GUI will be rendered differently on OSX/Windows.


#4

That’s true, but I’m pretty sure there’ll be people who rely on that behaviour on windows when scale factors are non-integer. Would be great one day to just change all the graphics coords to be exclusively float, and avoid this kind of thing


#5

We are having similar problems that the UI renders differently on Windows and OSX, I do something like:

auto bounds = getLocalBounds();
component1.setBounds(bounds.removeFromRight(10));
bounds.removeFromRight(1);
component2.setBounds(bounds.removeFromRight(10));

And there is no space between the two components… This happens on a scaling 125% which is used alot on Windows 10.


#6

Hi Andreas,
its totally normal that with a non integer scaling factor, that calculated pixel positions may will collapse on the same physical position.
Example:
if the non-scaled coordinates are 2 and 3, they will transformed to 2,5 and 3,75 (with scaling 1,25) and will be part-wise mixed on the same physical pixel 3.
The problem described in this topic is that there is a graphic function doesn’t work this way: the int version of fillRect. If you use this function, you should replace it with the float version, so you can be sure it will look nearly the same on both platforms (if they use the same scaling)