FLTK 1.3.9 gl_draw() problems on M1 Macs

[ptepa]

Describe the bug
On my M1 Mac, gl_draw sometimes crashes.
After my HACK to avoid this crash, it fails to display red text or displays it with very low alpha (nearly invisible).

To Reproduce
PROBLEM 1: gl_draw() sometimes crashes at '->as_gl_window()' with BAD_ADDRESS
but niether Fl_Window::current() nor 'as_gl_window' are null.
Here's my HACK that avoids these crashes, file gl_draw.cxx:
static void gl_draw_textures(const char* str, int n)
{
// BUG 1: 2024-03-28 ->as_gl_window() sometimes crashes with BAD_ADDRESS on M1 Macs!
// BUG 2: on M1 Macs text labels sometimes appear with very low alpha (opacity)!
#if defined( APPLE ) && defined( arm64 )
Fl_Gl_Window *gwin = 0; // HACK
#else
Fl_Gl_Window *gwin = Fl_Window::current()->as_gl_window();
#endif

PROBLEM 2: (after above HACK workaround), gl_draw() of red or green text does not show (or has very low alpha).
Steps to reproduce the behavior:

Edit file test/cube.cxx, search for gl_draw and add these outdented HACK test lines before it:

// TEMP HACK: try uncommenting one of the test lines below.
//glColor4f( 1.0, 0.0, 0.0, 1.0 ); // BUG: red text does not show.
//glColor4f( 0.0, 1.0, 0.0, 1.0 ); // BUG: green text does not show.
glColor4f( 0.0, 0.0, 1.0, 1.0 ); // blue text does show. WTF?

gl_draw(wire ? "Cube: wire" : "Cube: flat", -4.5f, -4.5f );

make ;./cube
Note that it correctly displays blue text.
Comment-out the line that sets color to blue and uncomment the line that
sets color to red then recompile and rerun.
make ; ./cube
Red text does not appear.
Tests show that white, gray or blue text appears but not red or green text.

Expected behavior
It should display any color text with alpha = 1.0.

Screenshots

FLTK Version

• Version: 1.3.9
• Downloaded and self-built from: fltk.org

FLTK Configure / Build Options
./configure --enable-debug --enable-localjpeg --enable-localpng --enable-localzlib
make

Operating System / Platform:
MacBookAir M1 (arm64) processor, Apple GPU, MacOS 12.5.1, OpenGL 2.1, g++ = Apple clang version 14.0.0.

Additional context
All Apple Macs use textures for text.
FLTK 1.3.9 works correctly on my Intel (x86_64) Mac, ATI Radeon Pro GPU, OpenGL 2.1, g++ = Apple LLVM version 9.0.0.

[MatthiasWM]

Too late at night to look at it right now. I have a MacBook Pro M1 here and can test stuff if you could post a compilable program here that show the bug.

In case you are using an OpenGL 3 context: With the M1, OpenGL can only be either OGL1 or OGL3. The OGL driver is currently only available in OGL1, and gl_draw is one of the calls affected. Manolo is doing some magic trickery here to switch between 1 and 3.

Lastly to my greatest disappointment, OpenGL on macOS is deprecated, and luckily still available, but I don't expect much driver fixing if this is and OS issue.

[ptepa]

Hi Matthias,
The test program is fltk1.3.9/test/cube.cxx
Search for gl_draw then add the glColor4f call below before gl_draw.
glColor4f( 1.0, 0.0, 0.0, 1.0 ); // BUG: red text has very low alpha (nearly invisible).
gl_draw(wire ? "Cube: wire" : "Cube: flat", -4.5f, -4.5f );
then make ; ./cube
It shows the text label in red but with very low alpha (almost invisible).
I used Keynote app's Text Color dialog magnifier (eye-dropper icon)
to examine the area where the text is drawn to see the red pixels that are almost invisible.

I'm not sure about GL Context. Perhaps FLTK sets it?
My Mac is running OpenGL version 2.1 Metal - 76.3

[ManoloFLTK]

OK. I tried test/cube with the 1-line addition on my MacBook Pro M1 and obtain a bright red:

Details about hardware settings here:

Added later:
This is with FLTK 1.4, the head of the git repo. I now realize you mention FLTK 1.3.9. I will test that now.

[ManoloFLTK]

OK. I confirm that with FLTK 1.3.9 text in red color is invisible. I add that only the blue component of colors is visible, green is invisible too.

@MatthiasWM Can you explain where does the GL code of 1.3.9 use the blue component as mask to create the textures used to draw text in a GL scene? That is either in gl_texture_fifo::compute_texture() or gl_texture_fifo::display_texture() of file src/gl_draw.cxx . This problem does not occur in 1.4.

@ptepa Can you use FLTK 1.4 under macOS instead of 1.3.9? That would solve "PROBLEM 2".

[ManoloFLTK]

PROBLEM 1: gl_draw() sometimes crashes at '->as_gl_window()' with BAD_ADDRESS
but neither Fl_Window::current() nor 'as_gl_window' are null.

That problem looks very much either

• a mix of FLTK versions between header files of the FLTK library and of your application causing conflict in the layout of class Fl_Window and its virtual member functions
  or
• a memory bug in your application which, of course, can cause any sort of problem

because
Fl_Gl_Window *gwin = Fl_Window::current()->as_gl_window();
should be OK if Fl_Window::current() is not NULL.

[ptepa]

Where can I get the configure file for this fltk-master?

(I tried and failed to get/build autoconf, gnulib-tool, etc... and the fltk-1.3.9 configure file did not work because there are no FL and GL subdirectories)

[Albrecht-S]

Where can I get the configure file for this fltk-master?

We recommend to use CMake which doesn't require configure (but of course an installation of CMake which you can pull from cmake.org).

If this doesn't work for you, you can either install autoconf with homebrew (if that's feasible) or, as documented in README.macOS.md:

Alternatively, _autoconf_ can be installed without _brew_ as follows :

- Download file _autoconf-latest.tar.gz_ from the <a href=https://ftp.gnu.org/gnu/autoconf/>autoconf ftp site</a>
- Uncompress it to get directory _autoconf-x.xx/_ (where x's indicate autoconf's version number)
- Set this directory as your current directory in the Terminal app and type :

```bash
./configure
make

OTOH you can download a current FLTK 1.4 snapshot from our download page which contains the configure script and should build w/o autoconf.

Edit: you could also download the snapshot, expand it, and copy only the configure script to your Git/fltk/master working directory.

[ManoloFLTK]

I believe the cure is to make this change in file scr/gl_draw.cxx, function gl_texture_fifo::compute_texture().

Replace these 3 lines #498ff

    GLfloat colors[4];
    glGetFloatv(GL_CURRENT_COLOR, colors);
    fl_color((uchar)(colors[0]*255), (uchar)(colors[1]*255), (uchar)(colors[2]*255));

by this single statement:
fl_color(FL_WHITE);

@ptepa Can you confirm this fix?

[MatthiasWM]

Manolo, I fund the bug and I am fixing it now. It's a bit more involved than just that. The order of color components is wrong. Try to put an emoji into the text and you will see what I mean. No worries though, I m almost done for 1.3.

[MatthiasWM]

Also, the cache textures must already be colored and marked as such, and the alpha channel is rendered later when compositing. Sorry, I should have assigned the bug to me sooner.

[MatthiasWM]

Thanks.

[MatthiasWM]

For 1.3, this is fixed in 20138be . To test, try various RGBA values, and for extended testing, add an Emoji to the text. Note that the emoji color is static despite different RGB values, but does render with the requested alpha. Now in 1.4, I assume that the underlying bug is also there, but the fix may be different. I'll be back.

[MatthiasWM]

@ManoloFLTK Ok, so looking at 1.4, you use the more resource efficient alpha channel for rendering text, which is great for 99% of all cases. In 1.3, you used and RGBA buffer and allowed rendering of colorful Emojis.

Question: would you want to leave alpha channel rendering as is in 1.4 and we are done, or would you want me to adapt the 1.3 code which needs 4 times more cache and is probably rarely used - but correct if fonts use color?

[ManoloFLTK]

@MatthiasWM
I'm still fundamentally ignorant about GL, so unqualified here.
I notice that emoji characters draw in the single text color under Windows, so the business of keeping them colored seems secondary to me.

Added later: I see that, under Windows, emojis draw with colors in some contexts (e.g., the search box of the file manager window) but in monocolor form in other contexts (e.g., NotePad++, terminal, when put in a filename).

I see also that FLTK 1.4 presently renders emojis in grey-colored GL text this way:

as opposed to what 1.3 does, now, after your fix:

which is still something else (and probably suboptimal for 1.4) than what Windows does when it doesn't render them colorful (an emoji-containing filename is shown here):

Being ignorant about GL, I would prefer to let you, please, decide what is most likely to be expected by users for text on a GL scene.

[MatthiasWM]

Well, your OpenGL ignorance implement some very cool code for text rendering. Thank you for that. I used OpenGL 1 in my old job very long ago, so this is relatively easy for me. But I must really learn OpenGL 3, now that 4 is even out (sigh).

macOS is very good about rendering emojis. X11 was never prepared for colored text, I assume, and it's probably similar with win32. FLTK's handling of Unicode is not perfect either, so for now, I think we just leave it as is.

[ManoloFLTK]

Ian, really, is the author of the code that uses textures to draw GL text.

I would believe this issue may be closed now.

[MatthiasWM]

Closing this as fixed. It fixes the issues with 1.3. For 1.4, the single color approach seems fine for now because neither Windows nor X11 seem to support colored fonts anyway, so it would be a waste of resources. Not sure about Wayland.