[vtk-developers] HiDPI / Retina displays and vtkTextActors

[Elvis Stansvik]

2017-10-16 16:52 GMT+02:00 Sean McBride <sean at rogue-research.com>:
> On Sat, 14 Oct 2017 11:39:29 +0200, Elvis Stansvik said:
>
>>> Thanks for the quick reply and suggestion.  We just tried this, and
>>indeed it works.  Specifically, we did SetDPI(144), we didn't actually
>>try to do any introspection of the actual DPI of the actual monitor.
>>
>>I'm using GetRenderWindow()->SetDPI(q
>>Round(QGuiApplication::primaryScreen()->logicalDotsPerInch()))
>>in our Qt/VTK app. i.e. using Qt to query for the DPI of the actual
>>monitor.
>
> I'm not at all convinced it's better to use the actual screen DPI to achieve this.  The API to get that info on macOS is IODisplayCreateInfoDictionary(), and has just a couple of hundred google results.  It does not seem at all typical to use DPI information.  From what I can tell, the way everyone handles Retina displays is a 2x doubling.

Alright, yes what I did in our application was mostly a band-aid solution.

>
> Consider how using the actual DPI would affect the screenshot in the start of this thread... the relative sizes of the cone & text would be different on different screens.  Seems just as undesirable as the current situation.

Yes, you're probably right. In our case, using Qt's
logicalDotsPerInch() was good enough for now.

>
>>Of course, this in itself doesn't take care of DPI changes, and it's
>>been on my TODO to fix this (listen for screen changes).
>
> You might also want to not hardcode 'primaryScreen' in there... :)

Yea, it really was a half-hearted fix. Glad this thread reminded me I
should fix it properly :)

Elvis

>
>>It looks like your MR is making VTK do this automatically internally
>>on macOS?
>
> Yes, basically.
>
>>That would be a welcome addition indeed, but what about
>>other platforms?
>
> Probably desirable there too, but outside my expertise...
>
> Sean
>
>