You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
FX2D renderer behaves inconsistently using surface.setSize(), displayHeight, displayWidth #9
Under the default Renderer, a combination of displayHeight, displayWidth and surface.setSize() can be used to set the window size to a specified portion of the screen size.
Under the FX2D-Renderer, displayHeight and displayWidth report the same values, but surface.setSize() seems to adhere to the Windows scaling factor on HighDPI displays, (similar to all other drawing calls, which seem to not work on screen pixels anymore).
Expected Behavior
surface.setSize() should work on the same pixel metric as displayHeight and displayWidth, or there should be another way to specify the window size as a portion of the screen size.
Current Behavior
There is no way from within processing to achieve a drawing size relative to the current screen size.
Steps to Reproduce
Execute the code below on highDPI Windows with a scaling factor >100%. The drawing height and width will be scaled by the windows scaling factor for FX2D, but not for the default renderer.
I attached the output for Default/FX2D and scaling factors 100%/150% below.
Your Environment
Processing version: .3.7
Operating System and OS version: Windows 10, all updates (07/2018)
Other information: Bug depends on scaling factor set in Windows. (Note: This is mandatory to be different from 100% on highDPI windows! It's not an edge case!)
Possible Causes / Solutions
displayDensity() could return a float instead of an int and capture this scaling factor as well.
surface.setSizeInScreenPixels() could be introduced.
Activity
gohai commentedon Jul 27, 2018
@B3ret I have yet to use the experimental FX2D renderer myself, but this looks like a thorough report - thanks for including the screenshots!
dgray001 commentedon Feb 26, 2022
Got this issue today only after upgrading to processing 4.