Oh, I see. Yes, it looks like you are right. Since Windows is the only
platform using platformWidth (and platformHeight), it might be possible
to refactor it, but only if we can guarantee that (width *
platformScaleX) == platformWidth, which would allow the Windows glass
code to compute it for each screen (since there is no per-platform
subclass of Screen). Alternatively, we could add a comment to the effect
that those variables are unused for platforms other than Windows.
-- Kevin
On 6/4/2021 12:43 AM, Johan Vos wrote:
Hi John, Kevin,
Thanks for the replies.
The relation between actual resolution of the Screen and the JavaFX
rendering is kept in the renderScale and outputScale, and does not
come from platformWidth. The value of platformWidth is never used
apart from the 2 methods I pointed out above.
The first reason I started this is because it is already complex with
a viewScale, platformScale, renderScale and outputScale, and I don't
see where the platformWidth fits in this picture -- especially since
the latter is not used at all on linux/mac.
The second reason is that I am looking into a more generic way to deal
with output dimensions that don't match the dimensions of the JavaFX
main texture. We currently support linear scaling with those scale
factors, but for some local work, I added rotation as well (e.g. to
allow rendering on a portrait screen when the source is in landscape
coordinates). This works surprisingly well by only manipulating the
transformation in ES2SwapChain.prepare (adding the rotation there). I
am doing that now conditionally, based on (yet even more) system
properties, but it might make sense to add an "orientation" parameter
to the Screen. But before adding something, I first try to see if
there is something unused that can be removed -- hence my question
about platformWidth/Height.
- Johan
On Fri, Jun 4, 2021 at 12:04 AM Kevin Rushforth
<kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
The platformWidth / platformHeight can also be different from the
width
/ height on Linux with Hi-DPI scaling, at least in theory, since the
Screen constructor is called using different parameters for the
platform
values. Mac is different because of how the retina scaling is
handled on
macOS -- even on a retina display, platformWidth/platformHeight ==
width/height and platformScale{X,Y} == 1.
-- Kevin
On 6/3/2021 2:38 PM, John Hendrikx wrote:
> Perhaps an example will help from my machine.
>
> I'm running on a 4k screen at 150% scaling. These are the values:
>
> outputScaleX = 1.5
> outputScaleY = 1.5
> platformScaleX = 1.5
> platformScaleY = 1.5
> width = 2560
> height = 1440
> visibleWidth = 2560
> visibleHeight = 1400
> platformWidth = 3840
> platformHeight = 2160
>
> So it seems that platform values report the actual resolution of
the
> Screen / Monitor. Probably they're what is being reported by
Windows
> and stored there by JavaFX to derive the actual width/height it
should
> use while taking scaling into account.
>
> You didn't ask about the difference between visibleHeight and
height.
> But just incase, the visibleHeight is 40 pixels smaller than
height,
> as this space is taken up by the task bar.
>
> --John
>
>
> On 01/06/2021 13:27, Johan Vos wrote:
>> Hi,
>>
>> com.sun.glass.ui.Screen has 3 width (and height) parameters,
each with a
>> getter:
>> * width
>> * visibleWidth
>> * platformWidth
>>
>> The latter seems to be used only in the windows build,
>> via screen.containsPlatformRect and
screen.portionIntersectsPlatformRect
>>
>> I don't really understand what the goal of this
platformWidth/Height
>> is. It
>> seems a bit artificial if this is not used on the other
platforms, but I
>> might be missing the bigger purpose of this?
>>
>> - Johan
>>
