What is the status of font rendering with JOGL?

I last checked in here some years ago and work was happening to enable hardware accelerated font rendering with JOGL.

Could someone please outline what has happened to this initiative and what the current status of rendering fonts and text with JOGL is?

Is it yet possible to achieve high quality font rendering or even sub-pixel font rendering?

Thanks,

-R

On 5/25/19 6:37 PM, Rosethornian [via jogamp] wrote:
> I last checked in here some years ago and work was happening to enable
> hardware accelerated font rendering with JOGL.
>
> Could someone please outline what has happened to this initiative and what the
> current status of rendering fonts and text with JOGL is?
>
> Is it yet possible to achieve high quality font rendering or even sub-pixel
> font rendering?

It depends.
There are still a few issues with the core code,
however - it is surely possible to use it as demonstrated
in some unit test w/ video etc.
It actually is being used within a scene in at least
one bigger project.

However .. from the top of my mind, issues are:
- bug in tesselation (sic), visible w/ certain fonts

- wrong alpha-blending w/o gamma (same as freetype)

- hence best results are w/ less contrast currently, not b/w

- subpixel, you name it & reading my mind, as I was playing
  w/ it lately while brushing up my knowledge on fonts,
  as you can read above :)

Only issue w/ me is priorities and hence lack of funding.
But after some other duties I love to tackle this one,
once again this summer. The sooner the better of course.

The overall funding thing, if everything fails,
I may need to kick off some 'brutal' & ugly fundraiser
campaign similar to PHK, see <http://phk.freebsd.dk/VML/>.
We will see ..

Bottom line, the work already done on curve rendering
is too valuable to be put to waste (IMHO).

But some 2-3 month might be required to make some good
progress, see wiki feature page re graph/curve rendering.

~Sven

>
> Thanks,
>
> -R

To test the Jogamp JOGL font rendering i have made a small test program and compile script:

git clone https://github.com/xranby/jogamp-forum-examples
cd jogamp-forum-examples/src/main/java
sh fetch-jogamp-build-and-run.sh



The font rendering is working on single board computers such as the raspbnerry pi.
Here tested on a Raspberry Pisystem with a 7" TFT
raspi-config i have selected G2 GL (Fake KMS) OpenGL desktop driver with fake KMS
For this to work with the current jogamp release i had to remove /opt/vc/lib from the library search path
mv /opt/vc /opt/vc2

On 5/29/19 5:37 PM, Xerxes Rånby [via jogamp] wrote:
On a side note, I used my old RaspiPi and
the new open source driver w/ ES2 and passed most unit tests.

Now I have finally the arm64 board on my desk and must find
a good Debian alike image to use w/ those full open source
drivers included .. Xerxes, you probably know which is the best?

Then, depending on performance, I may add this node for unit tests.

~Sven

The Gentoo Rpi3 64bit includes full OpenGL acceleration including the 7" touchscreen out of the box. sakaki- who maintains this Gentoo image have done a superb job.
https://github.com/sakaki-/gentoo-on-rpi3-64bit
JogAmp runs on 64bit arm using this Gentoo image.

Fedora aarch64 did work fine with HDMI and OpenGL however the 7" TFT did not work last time i tested.
https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi

Debian have some test images for aarch64 but they require a lot of manual setup before you can use them with OpenGL:
https://wiki.debian.org/RaspberryPi3

Arch linux also have Raspberry Pi aarch64 support with some manual setup.
https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3

On 5/29/19 6:26 PM, Xerxes Rånby [via jogamp] wrote:
Thank you.

So I assume Gentoo and Arch Linux expose the newest software versions?

Further I intend to use encapsulated OS images
for building and testing the binaries
for the purpose of having a SHA256 defined build system
to ensure SCC identity (known build environment + sources).
<http://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#Source_Certification_Contract_.28SCC.29>

To all: What would be the easiest and best encapsulation?
In a way a chroot would suffice :)
Surely not so easy on the Windows/OSX side of the medal.
Not a too pressing thing, but a nice to have.
Will update myself about it after 2.4.0.

Probably should create discussion threads for each,
so, all please forgive me for brainstorming.

~Sven

Yocto and Buildroot are both good tools if you want to bring up a working system and a build environment for embedded systems from sourcecode. When using Yocto or Buildroot the whole build can be done deterministic.

I have tested to use Buildroot to compile custom aarch64 rasperry pi 3 systems with minimal footprint with OpenGL support using the mesa vc4 drivers directly from eaarly init after Linux is loaded by using the Linux kernel modesetting drm-kms driver api.

I explored the possibility to run Jogamp on the Linux kernel modesetting drm-kms api however it require some new ways to initialize EGL in Jogl because the drm-kms api did not work with EGL default device instead you had to initialize EGL using an extension.
eglGetPlatformDisplayEXT(EGL_PLATFORM_GBM_KHR, gbm->dev, NULL);
https://gitlab.freedesktop.org/mesa/kmscube
https://gitlab.freedesktop.org/mesa/kmscube/blob/master/common.c#L164-235

Sven Gothel wrote

On 5/29/19 6:26 PM, Xerxes Rånby [via jogamp] wrote:
> The Gentoo Rpi3 64bit includes full OpenGL acceleration including the 7"
> touchscreen out of the box. sakaki- who maintains this Gentoo image have done
> a superb job.
> https://github.com/sakaki-/gentoo-on-rpi3-64bit
> JogAmp runs on 64bit arm using this Gentoo image.
>
> Fedora aarch64 did work fine with HDMI and OpenGL however the 7" TFT did not
> work last time i tested.
> https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
>
> Debian have some test images for aarch64 but they require a lot of manual
> setup before you can use them with OpenGL:
> https://wiki.debian.org/RaspberryPi3
>
> Arch linux also have Raspberry Pi aarch64 support with some manual setup.
> https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3

Thank you.

So I assume Gentoo and Arch Linux expose the newest software versions?

Further I intend to use encapsulated OS images
for building and testing the binaries
for the purpose of having a SHA256 defined build system
to ensure SCC identity (known build environment + sources).
<http://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#Source_Certification_Contract_.28SCC.29>

To all: What would be the easiest and best encapsulation?
In a way a chroot would suffice :)
Surely not so easy on the Windows/OSX side of the medal.
Not a too pressing thing, but a nice to have.
Will update myself about it after 2.4.0.

Probably should create discussion threads for each,
so, all please forgive me for brainstorming.

~Sven

On 5/29/19 7:45 PM, Xerxes Rånby [via jogamp] wrote:
> Yocto and Buildroot are both good tools if you want to bring up a working
> system and a build environment for embedded systems from sourcecode. When
> using Yocto or Buildroot the whole build can be done deterministic.
>
> I have tested to use Buildroot to compile custom aarch64 rasperry pi 3 systems
> with minimal footprint with OpenGL support using the mesa vc4 drivers directly
> from eaarly init after Linux is loaded by using the Linux kernel modesetting
> drm-kms driver api.

Nice, thank you. Will check after 2.40.

>
> I explored the possibility to run Jogamp on the Linux kernel modesetting
> drm-kms api however it require some new ways to initialize EGL in Jogl because
> the drm-kms api did not work with EGL default device instead you had to
> initialize EGL using an extension.
> eglGetPlatformDisplayEXT(EGL_PLATFORM_GBM_KHR, gbm->dev, NULL);
> https://gitlab.freedesktop.org/mesa/kmscube
> https://gitlab.freedesktop.org/mesa/kmscube/blob/master/common.c#L164-235

Yes, did EGL drivers and 'headless' GL glue-ing myself in the past
and such things brought up w/ JOGL for like TV sets.
Technically no problem, sometimes you might even get some poor
native windows via layers :)

All doable and would reduce the bringup costs dramatically of course,
add a nice hibernation mode and kick-off should be < 1s.

~Sven