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

[Marcus D. Hanwell]

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.

Thanks,

Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20180828/b8b3c0a2/attachment.html>