Many thanks for the clarification.
I'd also like to be more specific on the performance drop I observed but
I have to
admit that I don't have any idea what is going on there. The only thing
I can say
for sure is that I can consistently reproduce this drop in performance
by switching
between 8u45 and 8u60 (tested with b08 and b15).
My application contains a map view (something similar to Google Maps) which
displays an area of retina map tiles. By dragging with the mouse I can
move this
map around within the map pane. This works smoothly with 8u45 but is
completely
shaky with 8u60. I even experimented with various techniques to
implement such
a map view (single large image, single large canvas, individual
images/canvases for
each map tile) and they all show the same behavior, so it cannot be
something which
is specific to a particular implementation approach. During my test all
tiles where already
cached in memory, so I can exclude any file or network IO related issues.
I tried to implement a little example where I just move around a large
image but in
this simple scenario the problem does not show up.
So in order to do a bit more precise measuring I added an AnimationTimer
to my map pane
which I use to compute a new position of the map for each frame so that
a point on the map
moves along a circle. This helps to show the performance drop more
precisely than moving
around the map by hand. This is a smooth movement with 8u45 but shaky
with 8u60.
But one other observation puzzles me completely. The handle-method of
the timer is called with
a frame rate of 60 Hz even though the graphics output is shaky and has a
visual frame rate
of something between 2 - 5 Hz. It is new to me that something like this
is technically possible.
It looks as if the system is running at full speed but skips displaying
most of the generated
frames for some reason. Is such a behavior possible at all?
Am 05.06.15 um 22:49 schrieb Jim Graham:
I actually use a retina MBP for testing - dual booting Windows and MacOS.
There should be no changes at all on other platforms, particularly in
regard to rendering speed. There was one small regression on Linux
resulting in a bad first paint due to asynchronous initialization of
the Window size, but no performance issues. Can you be more specific
about where you see the performance drop? What kind of scene
graph/animation?
The system properties are all Windows specific, thus the "glass.win"
prefix. In 9 we might generalize all of the HiDPI support and offer
something more centralized, but those are just there for testing the
new Windows support for now. We'll also look at how to advertise the
pixel scaling to applications at that time.
One thing to note is that the way that Mac retina support is done, if
the user ever sets their control panel to anything other than "just
pick the best conditions for this display" then there is pixel-scaling
going on behind the scenes in the OS, so any attempts to try to line
up with pixels will be muddied by the virtual DPI they are emulating
at the system level. We'll also be looking at ways to bypass their
built-in "virtualized" HiDPI support in a later release so that we can
actually talk directly to display pixels regardless of CP settings.
This virtualized scaling is mitigated by the fact that this HiDPI
pixel stretching is happening on a HiDPI display and so any linear
interpolation is hidden by tiny pixel sizes.
To that end, we are doing something similar with Windows scaling.
There are a number of places in the FX code that assume that it can
predict an integer translation from the FX code and so we always
render at integer scales so that integers in FX Scene coordinates map
to integers in rendered pixel coordinates. We'll try to fix those in
9 so that we can do non-integer scaling, but until then there will be
the same disconnect between trying to line up with display pixels and
the actions of HiDPI as Mac OS already has...
...jim
On 6/5/15 3:03 AM, Dr. Michael Paus wrote:
I cannot provide any Windows specific feedback on HiDPI displays because
I don't own one but I am working on a MacBook Pro with Retina display
and thus would like to ask a few questions in this context.
How are other platforms (Mac, Linux) affected by the changes you made
for the Windows support? (On my Mac I noticed a severe performance drop
when using 8u60 which may possibly be related to these changes.)
Are any of the special system properties you mentioned also usable on
other platforms?
Is there any way now to find out what the current pixel scale factor is?
Without that knowledge it is impossible to do proper graphics on any
HiDPI screen. (E.g., you can't position graphic elements correctly in
order to get crisp lines or you can't get a crisp snapshot of a node if
you don't take special actions based on the pixel scale.)
