Building Scilab with JoGL 2.4.0

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

Building Scilab with JoGL 2.4.0

mottelet
Hello, I am currently in charge of OSX version of Scilab, which uses JoGL (2.2.4) for a while now. There are currently two problems, one with Mojave (NSWindow drag regions shoud only be invalided in the main Thread) and the other one with Retina displays (tiny fonts and other glitches due to high DPI).

I have downloaded the latest master build at http://jogamp.org/deployment/archive/master/gluegen_916-joal_642-jogl_1483-jocl_1122/archive/jogamp-all-platforms.7z and am able to build Scilab. Using JoGL 2.4.0 solves the NSWindow problem under Mojave, but the problem with Retina display remains. So my question is : since building with joGL 2.4.0 does not solve the DPI problem for Scilab, maybe do we have to change the way we use the joGL api ?

Thanks for your help,

S.
Reply | Threaded
Open this post in threaded view
|

Re: Building Scilab with JoGL 2.4.0

Sven Gothel
Administrator
On 5/29/19 3:19 PM, mottelet [via jogamp] wrote:

> Hello, I am currently in charge of OSX version of Scilab, which uses JoGL
> (2.2.4) for a while now. There are currently two problems, one with Mojave
> (NSWindow drag regions shoud only be invalided in the main Thread) and the
> other one with Retina displays (tiny fonts and other glitches due to high DPI).
>
> I have downloaded the latest master build at
> http://jogamp.org/deployment/archive/master/gluegen_916-joal_642-jogl_1483-jocl_1122/archive/jogamp-all-platforms.7z and
> am able to build Scilab. Using JoGL 2.4.0 solves the NSWindow problem under
> Mojave, but the problem with Retina display remains. So my question is : since
> building with joGL 2.4.0 does not solve the DPI problem for Scilab, maybe do
> we have to change the way we use the joGL api ?

Please pick on of the High-DPI bugs (see wiki features for overview)
and create a new followup bug with detailed description
and best: small unit test.
I hope to be able to go through these dpi issues before the release
or shortly thereafter.

But to understand each scenario best, a small unit test attached
or via git patch would help most.

Thank you

~Sven
Reply | Threaded
Open this post in threaded view
|

Re: Building Scilab with JoGL 2.4.0

mottelet
Sven Gothel wrote
On 5/29/19 3:19 PM, mottelet [via jogamp] wrote:
> Hello, I am currently in charge of OSX version of Scilab, which uses JoGL
> (2.2.4) for a while now. There are currently two problems, one with Mojave
> (NSWindow drag regions shoud only be invalided in the main Thread) and the
> other one with Retina displays (tiny fonts and other glitches due to high DPI).
>
> I have downloaded the latest master build at
> http://jogamp.org/deployment/archive/master/gluegen_916-joal_642-jogl_1483-jocl_1122/archive/jogamp-all-platforms.7z and
> am able to build Scilab. Using JoGL 2.4.0 solves the NSWindow problem under
> Mojave, but the problem with Retina display remains. So my question is : since
> building with joGL 2.4.0 does not solve the DPI problem for Scilab, maybe do
> we have to change the way we use the joGL api ?

Please pick on of the High-DPI bugs (see wiki features for overview)
and create a new followup bug with detailed description
and best: small unit test.
I hope to be able to go through these dpi issues before the release
or shortly thereafter.

But to understand each scenario best, a small unit test attached
or via git patch would help most.

Thank you

~Sven
In the code where we create a GLJPanel I have inserted something to printout getMaximumSurfaceScale() and getMinimumSurfaceScale(). When I run Scilab both give me {1,1} regardless of the actual display hardware, Retina or classical DPI display. Should I obtain {2,2} on a Retina display ?
Reply | Threaded
Open this post in threaded view
|

Re: Building Scilab with JoGL 2.4.0

mottelet
mottelet wrote
Sven Gothel wrote
On 5/29/19 3:19 PM, mottelet [via jogamp] wrote:
> Hello, I am currently in charge of OSX version of Scilab, which uses JoGL
> (2.2.4) for a while now. There are currently two problems, one with Mojave
> (NSWindow drag regions shoud only be invalided in the main Thread) and the
> other one with Retina displays (tiny fonts and other glitches due to high DPI).
>
> I have downloaded the latest master build at
> http://jogamp.org/deployment/archive/master/gluegen_916-joal_642-jogl_1483-jocl_1122/archive/jogamp-all-platforms.7z and
> am able to build Scilab. Using JoGL 2.4.0 solves the NSWindow problem under
> Mojave, but the problem with Retina display remains. So my question is : since
> building with joGL 2.4.0 does not solve the DPI problem for Scilab, maybe do
> we have to change the way we use the joGL api ?

Please pick on of the High-DPI bugs (see wiki features for overview)
and create a new followup bug with detailed description
and best: small unit test.
I hope to be able to go through these dpi issues before the release
or shortly thereafter.

But to understand each scenario best, a small unit test attached
or via git patch would help most.

Thank you

~Sven
In the code where we create a GLJPanel I have inserted something to printout getMaximumSurfaceScale() and getMinimumSurfaceScale(). When I run Scilab both give me {1,1} regardless of the actual display hardware, Retina or classical DPI display. Should I obtain {2,2} on a Retina display ?
I finally solved the problem with replacing GLJPanel methods getSurfaceWidth() and  getSurfaceHeight() with getWidth() and getHeight() in a strategic place and now the scale of graphics is correct and even dynamically adapts when windows are moved to an external display. However, on the Retina display, the text objects mixed with graphics have correct size but look blurry, i.e. with a kind of extreme antialiasing. I have searched similar issues in the forum but how to fix this seems not evident to me. It seems to depend on OSX version and JRE version (we use 1.8 for Scilab).
Reply | Threaded
Open this post in threaded view
|

Re: Building Scilab with JoGL 2.4.0

Sven Gothel
Administrator
On 6/4/19 8:24 PM, mottelet [via jogamp] wrote:
> I finally solved the problem with replacing GLJPanel methods getSurfaceWidth()
> and  getSurfaceHeight() with getWidth() and getHeight() in a strategic place
> and now the scale of graphics is correct and even dynamically adapts when
> windows are moved to an external display. However, on the Retina display, the

Great, can you please point me to the code in your repo showing the change?
I am curious what the issue was.

> text objects mixed with graphics have correct size but look blurry, i.e. with
> a kind of extreme antialiasing. I have searched similar issues in the forum
> but how to fix this seems not evident to me. It seems to depend on OSX version
> and JRE version (we use 1.8 for Scilab).

I assume you are not talking about our GraphUI font?

~Sven

>     mottelet wrote
>
>         Sven Gothel wrote
>         On 5/29/19 3:19 PM, mottelet [via jogamp] wrote:
>         > Hello, I am currently in charge of OSX version of Scilab, which uses
>         JoGL
>         > (2.2.4) for a while now. There are currently two problems, one with
>         Mojave
>         > (NSWindow drag regions shoud only be invalided in the main Thread)
>         and the
>         > other one with Retina displays (tiny fonts and other glitches due to
>         high DPI).
>         >
>         > I have downloaded the latest master build at
>         >
>         http://jogamp.org/deployment/archive/master/gluegen_916-joal_642-jogl_1483-jocl_1122/archive/jogamp-all-platforms.7z and
>
>         > am able to build Scilab. Using JoGL 2.4.0 solves the NSWindow
>         problem under
>         > Mojave, but the problem with Retina display remains. So my question
>         is : since
>         > building with joGL 2.4.0 does not solve the DPI problem for Scilab,
>         maybe do
>         > we have to change the way we use the joGL api ?
>
>         Please pick on of the High-DPI bugs (see wiki features for overview)
>         and create a new followup bug with detailed description
>         and best: small unit test.
>         I hope to be able to go through these dpi issues before the release
>         or shortly thereafter.
>
>         But to understand each scenario best, a small unit test attached
>         or via git patch would help most.
>
>         Thank you
>
>         ~Sven
>
>     In the code where we create a GLJPanel I have inserted something to
>     printout getMaximumSurfaceScale() and getMinimumSurfaceScale(). When I run
>     Scilab both give me {1,1} regardless of the actual display hardware,
>     Retina or classical DPI display. Should I obtain {2,2} on a Retina display ?
>
> I finally solved the problem with replacing GLJPanel methods getSurfaceWidth()
> and  getSurfaceHeight() with getWidth() and getHeight() in a strategic place
> and now the scale of graphics is correct and even dynamically adapts when
> windows are moved to an external display. However, on the Retina display, the
> text objects mixed with graphics have correct size but look blurry, i.e. with
> a kind of extreme antialiasing. I have searched similar issues in the forum
> but how to fix this seems not evident to me. It seems to depend on OSX version
> and JRE version (we use 1.8 for Scilab).
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Building Scilab with JoGL 2.4.0

mottelet
Sven Gothel wrote
On 6/4/19 8:24 PM, mottelet [via jogamp] wrote:
> I finally solved the problem with replacing GLJPanel methods getSurfaceWidth()
> and  getSurfaceHeight() with getWidth() and getHeight() in a strategic place
> and now the scale of graphics is correct and even dynamically adapts when
> windows are moved to an external display. However, on the Retina display, the

Great, can you please point me to the code in your repo showing the change?
I am curious what the issue was.

...
The patch is under review @ https://codereview.scilab.org/#/c/20998/

It is not an optimal patch but does the job. The problem is that autoDrawable only has getSurfaceWidth() and getSurfaceHeight() (at least since 2.3.x, here I have tested with master/2.4.0). Depending on the hardware, it can be a GLJCanvas or a GLJPanel, but under Mac OSX I know that it is always a GLJPanel, which explains the brute force cast. If you have a better idea I am greatly interested.