[vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

[Elvis Stansvik]

2018-08-28 16:14 GMT+02:00 Marcus D. Hanwell <marcus.hanwell at kitware.com>:
> On Tue, Aug 28, 2018 at 1:23 AM Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>>
>> 2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell <marcus.hanwell at kitware.com>:
>> > On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik
>> > <elvis.stansvik at orexplore.com> wrote:
>> >>
>> >> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik
>> >> <elvis.stansvik at orexplore.com>:
>> >> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik
>> >> > <elvis.stansvik at orexplore.com>:
>> >> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik
>> >> >> <elvis.stansvik at orexplore.com>:
>> >> >>> Marcus, I found this (very) old post of yours where you linked to a
>> >> >>> Gerrit change in which (I believe) you fixed a problem with the
>> >> >>> string
>> >> >>> texture cache of vtkOpenGLContextDevice2D not being invalidated
>> >> >>> when
>> >> >>> the font size, color et.c. changes:
>> >> >>>
>> >> >>>
>> >> >>> https://www.vtk.org/pipermail/vtkusers/2011-November/071067.html
>> >> >>>
>> >> >>> The reason I'm asking is that I'm suspecting that, since the DPI is
>> >> >>> taken into account when these textures are created, the cache
>> >> >>> should
>> >> >>> be invalidated also when the DPI of the render window changes?
>> >> >>>
>> >> >>> I'm in a situation now where I'm trying to make our application
>> >> >>> react
>> >> >>> well to DPI changes, but a simple SetDPI on the render window, the
>> >> >>> axis label text sizes do not change. So I'm faced with perhaps
>> >> >>> having
>> >> >>> to recreate the entire chart when the DPI changes.
>> >> >>>
>> >> >>> Does it sound plausible that it could be the texture cache
>> >> >>> mentioned
>> >> >>> in that old thread?
>> >> >>
>> >> >> Nevermind, I've just discovered that something is mysteriously
>> >> >> re-setting the DPI to 72 after I set it.
>> >> >>
>> >> >> I'll have to investigate that issue instead.
>> >> >
>> >> > So the first time setEnableHiDPI is called (and there's a render
>> >> > window present), the DPI at that time is cached in this->OriginalDPI,
>> >> > and that DPI is used for subsequent calls.
>> >> >
>> >> > I don't see how this can work with runtime DPI changes (when the user
>> >> > calls SetDPI to set the appropriate DPI)?
>> >>
>> >> I can work around the problem by re-setting OriginalDPI to 0 directly
>> >> after I call SetDPI on DPI changes (I'm subclassing QVTKOpenGLWidget,
>> >> so have access to it), but I doubt this was intended?
>> >
>> >
>> > That is an old issue, I think we got it fixed, but I am not sure whether
>> > the
>> > font cache would be using the DPI as most of that work predated all
>> > this. I
>> > will try and take a look, but it is many years since I last looked at
>> > that
>> > code.
>>
>> Thanks. Just to clarify: With the hack above, it works fine - the text
>> rendering respects the set DPI.
>>
>> What I don't understand is the logic in setEnableHiDPI, because the
>> way it is written, it means that each time setEnableHiDPI is called
>> during runtime, the DPI will be re-set to whatever it was when
>> setEnableHiDPI was called the first time. And when using
>> QVTKOpenGLWidget, setEnableHiDPI is called on each recreateFBO call.
>> So it seems to me a user can never call SetDPI on the render window of
>> a QVTKOpenGLWidget and have it "stick". It will be re-set behind the
>> scenes :/
>>
> I was just looking at this yesterday, and agree with your diagnosis. I had
> overridden void setEnableHiDPI(bool enable) but the signature changed, and
> now don't see a good way to do that. I am also looking into font scaling
> issues, at least on Linux with a 4k high DPI display the chart fonts look
> tiny. I will try and do some more testing, the fonts in Qt look fine so it
> would appear to be an issue with our rendering somewhere.

Alright. The fonts looking tiny on Linux/4k is probably just a matter
of the text rendering not respecting devicePixelRatioF(). I'm guessing
the machine is running with QT_SCREEN_SCALE_FACTORS or
Qt::AA_EnableHighDpiScaling set, to enable Qt's built-in pixel
scaling?.

In my case, I was testing this on Windows with it's screen scaling
option set to 200%. But the Windows "screen scaling" is really just
about changing fonts/DPI/layouts AFAIK, and will not affect what the
Qt devicePixelRatioF() API reports.

So it was two different cases. I just wanted it to respect the DPI of
the screen (which it seems to do), while you want it to respect any
device pixel ratio in effect. I would like that as well of course,
because next on my list after fixing Windows HiDPI issues is Mac/Linux
:)

Making a Qt app work well on HiDPI on all three platforms, and in all
events (changing resolution, screen scaling, DPI) is really
non-trivial I've discovered :/

On Windows the situation is even worse, because if you run with Qt's
pixel-based scaling turned off (as is recommended for new apps in the
Qt docs), then there even seems to be built-in controls in Qt that
don't work well in a mixed-DPI setup (extended desktop on Windows), at
least not with the Win 10 Qt style, so you're sort of out of luck
(unless you want to use the Fusion style, which sort of negates one of
the strengths of Qt which is its native look).

Elvis

>
> Thanks,
>
> Marcus