[vtk-developers] HiDPI / Retina displays and vtkTextActors

[Elvis Stansvik]

2017-10-14 1:39 GMT+02:00 Sean McBride <sean at rogue-research.com>:
> Hi Allie,
>
> 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(qRound(QGuiApplication::primaryScreen()->logicalDotsPerInch()))
in our Qt/VTK app. i.e. using Qt to query for the DPI of the actual
monitor.

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).

It looks like your MR is making VTK do this automatically internally
on macOS? That would be a welcome addition indeed, but what about
other platforms?

Elvis

>
> This solution seems a bit unsatisfying, but I guess fine.  It would mean changing vtkCocoaGLView to register for OS notifications about moving between displays and then update its renderWindow's DPI in response.  Like this:
>
> <https://gitlab.kitware.com/vtk/vtk/merge_requests/3446>
>
> Unless there's a better idea....
>
> Sean
>
>
>
> On Wed, 11 Oct 2017 16:05:43 -0400, Allie Vacanti said:
>
>>Hi Sean,
>>
>>Have you tried setting the DPI on the render window (vtkWindow::SetDPI)?
>>The text actors should respect that.
>>
>>HTH,
>>Allie
>>
>>On Wed, Oct 11, 2017 at 3:44 PM, Sean McBride <sean at rogue-research.com>
>>wrote:
>>
>>> Hi all,
>>>
>>> We've been testing our app against VTK git master and have run into one
>>> HiDPI/Retina issue.
>>>
>>> In the attached screenshot (hopefully not too big for the list) we see two
>>> identical render windows except that the left one has Retina enabled, and
>>> the right one has it disabled.  (Indeed we see less aliasing with the left
>>> cone.)
>>>
>>> But notice the vtkTextActors.  The string appears half size in the left
>>> view.  I argue this is a bug.  To be clear, in both cases, we specified
>>> SetFontSize(30).
>>>
>>> It does not seem desirable to have to provide a different value to
>>> SetFontSize() depending on the display type (HiDPI or not).  With no other
>>> actor type, like the cones, does the display type matter.
>>>
>>> Presumably some code somewhere takes that font size and computes how many
>>> pixels tall/wide to make the text onscreen.  Perhaps it should doing
>>> something extra now?  I'm not sure how we should deal with this, so am here
>>> to discuss...
>>>
>>> Thanks,
>>>
>>> --
>>> ____________________________________________________________
>>> Sean McBride, B. Eng                 sean at rogue-research.com
>>> Rogue Research                        www.rogue-research.com
>>> Mac Software Developer              Montréal, Québec, Canada
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/
>>> opensource/opensource.html
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>