Windows support for HiDPI displays, call for feedback and testing

[Kevin Rushforth]

Does the same slowdown happen on a non-Retina system?

How large is your image? How large are the individual tiles? One thing 
that occurs to me is that your application might be thrashing texture 
memory (although I can't think of anything that changed in 8u60 that 
would affect this). You might try the following debug flag:

java -Dprism.poolstats=true

and see if there is a lot of thrashing of texture memory. Also, you can 
increase the memory that will be used for textures to, say, 1Gbyte 
(default is 512Mbytes) by:

java -Dprism.maxvram=1g

and see if that makes a difference. Jim might have additional suggestions.

-- Kevin


Dr. Michael Paus wrote:
> 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.)
>