[vtk-developers] DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache
elvis.stansvik at orexplore.com
Sat Aug 25 09:05:54 EDT 2018
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>:
>> Hi Marcus and all,
>> 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:
>> 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.
OK, I think there's some bug related to how setEnableHiDPI works (and
the fact that it's called in recreateFBO).
void QVTKOpenGLWidget::setEnableHiDPI(bool enable)
this->EnableHiDPI = enable;
if (this->OriginalDPI == 0)
this->OriginalDPI = this->RenderWindow->GetDPI();
this->RenderWindow->SetDPI(this->OriginalDPI * this->devicePixelRatio());
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)?
>> Many thanks in advance,
More information about the vtk-developers