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

[Marcus D. Hanwell]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20180827/0c640431/attachment.html>