DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Elvis Stansvik
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:

    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?

Many thanks in advance,
Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Elvis Stansvik
2018-08-25 14:04 GMT+02:00 Elvis Stansvik <[hidden email]>:

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

Elvis

>
> Many thanks in advance,
> Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Elvis Stansvik
2018-08-25 14:45 GMT+02:00 Elvis Stansvik <[hidden email]>:

> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik <[hidden email]>:
>> 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:
>>
>>     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.

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->RenderWindow)
  {
    if (this->OriginalDPI == 0)
    {
      this->OriginalDPI = this->RenderWindow->GetDPI();
    }
    if (this->EnableHiDPI)
    {
      this->RenderWindow->SetDPI(this->OriginalDPI * this->devicePixelRatio());
    }
    else
    {
      this->RenderWindow->SetDPI(this->OriginalDPI);
    }
  }
}

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)?

Elvis

>
> Elvis
>
>>
>> Many thanks in advance,
>> Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Elvis Stansvik
2018-08-25 15:05 GMT+02:00 Elvis Stansvik <[hidden email]>:

> 2018-08-25 14:45 GMT+02:00 Elvis Stansvik <[hidden email]>:
>> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik <[hidden email]>:
>>> 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:
>>>
>>>     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.
>
> 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->RenderWindow)
>   {
>     if (this->OriginalDPI == 0)
>     {
>       this->OriginalDPI = this->RenderWindow->GetDPI();
>     }
>     if (this->EnableHiDPI)
>     {
>       this->RenderWindow->SetDPI(this->OriginalDPI * this->devicePixelRatio());
>     }
>     else
>     {
>       this->RenderWindow->SetDPI(this->OriginalDPI);
>     }
>   }
> }
>
> 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?

Elvis

>
> Elvis
>
>>
>> Elvis
>>
>>>
>>> Many thanks in advance,
>>> Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Marcus D. Hanwell-2
On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik <[hidden email]> wrote:
2018-08-25 15:05 GMT+02:00 Elvis Stansvik <[hidden email]>:
> 2018-08-25 14:45 GMT+02:00 Elvis Stansvik <[hidden email]>:
>> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik <[hidden email]>:
>>> 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.

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Elvis Stansvik
2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell <[hidden email]>:

> On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik
> <[hidden email]> wrote:
>>
>> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik <[hidden email]>:
>> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik
>> > <[hidden email]>:
>> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik
>> >> <[hidden email]>:
>> >>> 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
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Marcus D. Hanwell-2
On Tue, Aug 28, 2018 at 1:23 AM Elvis Stansvik <[hidden email]> wrote:
2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell <[hidden email]>:
> On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik
> <[hidden email]> wrote:
>>
>> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik <[hidden email]>:
>> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik
>> > <[hidden email]>:
>> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik
>> >> <[hidden email]>:
>> >>> 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

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: DPI changes and invalidation of vtkOpenGLContextDevice2D string texture cache

Elvis Stansvik
2018-08-28 16:14 GMT+02:00 Marcus D. Hanwell <[hidden email]>:

> On Tue, Aug 28, 2018 at 1:23 AM Elvis Stansvik
> <[hidden email]> wrote:
>>
>> 2018-08-27 18:01 GMT+02:00 Marcus D. Hanwell <[hidden email]>:
>> > On Sat, Aug 25, 2018 at 9:33 AM Elvis Stansvik
>> > <[hidden email]> wrote:
>> >>
>> >> 2018-08-25 15:05 GMT+02:00 Elvis Stansvik
>> >> <[hidden email]>:
>> >> > 2018-08-25 14:45 GMT+02:00 Elvis Stansvik
>> >> > <[hidden email]>:
>> >> >> 2018-08-25 14:04 GMT+02:00 Elvis Stansvik
>> >> >> <[hidden email]>:
>> >> >>> 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
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers