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

[Elvis Stansvik]

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 :/

Elvis