GL root Fl_Gl_Window::draw

[Gonzalo Garramuno]

I am using OpenGL 4.1 on MacOS. I tried calling Fl_Gl_Window::draw() at the end of my GL viewport widget and was greeted with a crash in gl_draw / gl_font.
I am assuming the drawing of widgets in the GL context is just a OpenGL2 feature. Am I right?

—
Gonzalo Garramuno
ggar...@gmail.com

[Manolo]

You are right, because under macOS it's impossible to mix GL 3+ and GL2 calls in the same context.

 

[Albrecht Schlosser]

On 9/8/22 03:25 schrieb Gonzalo Garramuno wrote:
> I am using OpenGL 4.1 on MacOS. I tried calling Fl_Gl_Window::draw() at the end of my GL viewport widget and was greeted with a crash in gl_draw / gl_font.

I'm not sure if I understand this correctly. What means "at the end of
my GL viewport widget"? Does this mean at the end of the constructor?

I know nearly nothing about OpenGL but IIRC it is possible to use GL
drawing methods anywhere if you call the appropriate make_current()
method. However, at the end of the constructor (if my assumption is
true) the window is very likely not yet shown or at least not yet mapped
to the screen. Or something like that.

Otherwise, shouldn't you better wait until FLTK calls draw() on your
widget as with all other widgets/windows?

Or maybe I misunderstood your question or I'm talking nonsense...

> I am assuming the drawing of widgets in the GL context is just a OpenGL2 feature. Am I right?

Manolo answered this question already, but is this (mixing OpenGL 2 and
3+) really the cause? I believe you can also use OpenGL3+ on macOS if
you do it "correctly" (RTFM).
https://fltk.gitlab.io/fltk/opengl.html#opengl3

[Manolo]

I understood the question asked by Gonzalo is to use both OpenGL 4 and the new Fl_OpenGL_Graphics_Driver

which is GL 2-based under macOS.

If that is true, my reply was this is impossible for the reason given in the doc:

On the macOS platform, ……. FLTK creates contexts for OpenGL versions 1 and 2 without the FL_OPENGL3 flag and for OpenGL versions 3.2 and above with it.

Which means, you have to choose between using the old GL and then Fl_OpenGL_Graphics_Driver is possible, or the new GL (3.2 and above)

and then Fl_OpenGL_Graphics_Driver is impossible.

Notice this restriction is macOS-specific. The other 3 platforms allow mixing.

If Gonzalo asked something else, then my reply makes no sense necessarily.

[Greg Ercolano]

On 9/8/22 05:27, Albrecht Schlosser wrote:

On 9/8/22 03:25 schrieb Gonzalo Garramuno wrote:

I am using OpenGL 4.1 on MacOS.  I tried calling Fl_Gl_Window::draw() at the end of my GL viewport widget and was greeted with a crash in gl_draw / gl_font.

I'm not sure if I understand this correctly. What means "at the end of my GL viewport widget"? Does this mean at the end of the constructor?

    I read that to mean he's calling Fl_Gl_Window::draw() and the bottom of his widget's draw()
    because he (probably) has FLTK widgets that are children of his Fl_Gl_Window derived widget.

    According to the docs, your draw() is supposed to do all the GL stuff, then the last thing
    you do before return()ing is to call Fl_Gl_Window::draw() so that the child widgets can
    be drawn over your opengl drawing.

[Gonzalo Garramuño]

On 8/9/22 14:20, Greg Ercolano wrote:
>     I read that to mean he's calling Fl_Gl_Window::draw() and the
> bottom of his widget's draw()
>     because he (probably) has FLTK widgets that are children of his
> Fl_Gl_Window derived widget.
>
>     According to the docs, your draw() is supposed to do all the GL
> stuff, then the last thing
>     you do before return()ing is to call Fl_Gl_Window::draw() so that
> the child widgets can
>     be drawn over your opengl drawing.

Yes, that's exactly what I was trying to do.  On Linux and Windows this
works, but on macOS, as Manolo said, it does not, as it does not allow
mixing OpenGL2 and OpenGL3+ calls.  That sucks, as I was now relying on
that feature for my program.  It is a pity as the video library I am now
using requires OpenGL4.1, while FLTK is still stuck on GL2.

Oh well... one more thing the new rewrite of my program won't support.

[Manolo]

Gonzalo: you may try to put your GL widgets in a new Fl_Gl_Window object

with fully transparent background color, the same size as your GL4-using

window and positionned right above it. I didn't try that, but I see no reason

it should not work.

[imacarthur]

On Friday, 9 September 2022 at 03:19:40 UTC+1 Gonzalo wrote:

Yes, that's exactly what I was trying to do.  On Linux and Windows this
works, but on macOS, as Manolo said, it does not, as it does not allow
mixing OpenGL2 and OpenGL3+ calls.  That sucks, as I was now relying on
that feature for my program.  It is a pity as the video library I am now
using requires OpenGL4.1, while FLTK is still stuck on GL2.

Oh well... one more thing the new rewrite of my program won't support.

Bother - apologies if two versions of this reply appear. This is my second try; the web interface appears to have dropped my first (longer and more rambling) attempt somewhere...

Anyway,  the crux of my replay was that FLTK needs to use GL2 as that is the only API that we know is exposed by default on WIN32 and most X11/Wayland systems, and that is also available on macOS.

Further, to get "higher" GL API than 2.1, on WIN32 and most X11/Wayland systems you need to use an "extension wrangler" such as GLEW.

If we switch FLTK to use, say, GL3 as the default then that impacts a lot of use cases, and we'd need to look at bundling GLEW or a similar extension wrangler, at least for the Win32 usage. And that might not work as there are a lot of desktop systems that have really ancient GL driver support...

But *generally* this does not matter, since GL contexts are *generally* "backwards compatible" - on Win32 or X11 a GL4 context can still do GL2-ish things.

Apple seem to have contrived to make that not work. (At this point in the lost post I implied this was related to Apple being down on GL and trying to force people to use their proprietary API.)

So... I'm not convinced this is a problem of FLTKs making, or one that we can readily fix. Perhaps Apple will fix it...

 

[Gonzalo Garramuno]

That seemed like a nice hack. Unfortunately I was unable to make it work with the OpenGL3text.cxx example.

I still get a crash in the gl2 window object when It calls Fl_Gl_Window. And any glBegin()/End() for opengl2 lines or triangles and the like also don’t show.

Find attached the 3 tiny files I am using in case you can see something wrong.

—
Gonzalo Garramuno
ggar...@gmail.com

[Manolo]

@Gonzalo: I realize now my proposal was wrong.

The good solution is not to use a transparent GL2 window but a transparent normal window,

see attached example program which builds upon OpenGL3test.cxx :

[Gonzalo Garramuno]

That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).

—
Gonzalo Garramuno
ggar...@gmail.com

[imacarthur]

On Wednesday, 14 September 2022 at 20:41:51 UTC+1 Gonzalo wrote:

That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).

OK, so in looking for some old code to answer a question on fltk.general (Hi Gonzalo...) I found another bit of code I had.

If the question is about drawing a translucent FL window over a GL surface, I have code for this... Here's an example - it's GL2, but should Just Work.

//
// GL portions derived from:
// OpenGL example showing text on a rotating 3D object.
// erco 03/03/06
//
#include <FL/x.H>
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Gl_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Choice.H>
#include <FL/gl.h>
#include <GL/glu.h>
#include <string.h>
#include <stdio.h>

// First, Greg's 2D-text on GL scene expample, to give a dynamic GL scene to draw the dialog on top of
// Tetrahedron points
#define TOP    0,  1,  0
#define RIGHT  1, -1,  1
#define LEFT  -1, -1,  1
#define BACK   0, -1, -1

class MyGlWindow : public Fl_Gl_Window {
    float rotangle;
    void draw() {
        // First time? init viewport, etc.
        if (!valid()) {
            valid(1);
            // Initialize GL
            glClearColor(0.0, 0.0, 0.0, 0.0);
            glClearDepth(1.0);
            glDepthFunc(GL_LESS);
            glEnable(GL_DEPTH_TEST);
            glShadeModel(GL_FLAT);
        }
        glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
        // Position camera/viewport init
        glMatrixMode(GL_PROJECTION);
        glLoadIdentity();
        glViewport(0,0,w(),h());
        gluPerspective(45.0, (float)w()/(float)h(), 1.0, 10.0);
        glTranslatef(0.0, 0.0, -5.0);
        // Position object
        glMatrixMode(GL_MODELVIEW);
        glLoadIdentity();
        glRotatef(rotangle, 1, 0, 1);
        glRotatef(rotangle, 0, 1, 0);
        glRotatef(rotangle, 1, 1, 1);
        // Draw tetrahedron
        glColor3f(1.0, 0.0, 0.0); glBegin(GL_POLYGON); glVertex3f(TOP);   glVertex3f(RIGHT);  glVertex3f(LEFT);  glEnd();
        glColor3f(0.0, 1.0, 0.0); glBegin(GL_POLYGON); glVertex3f(TOP);   glVertex3f(BACK);   glVertex3f(RIGHT); glEnd();
        glColor3f(0.0, 0.0, 1.0); glBegin(GL_POLYGON); glVertex3f(TOP);   glVertex3f(LEFT);   glVertex3f(BACK);  glEnd();
        glColor3f(0.5, 0.5, 0.5); glBegin(GL_POLYGON); glVertex3f(RIGHT); glVertex3f(BACK);   glVertex3f(LEFT);  glEnd();
        // Print tetrahedron's points on object
        //     Disable depth buffer while drawing text,
        //     so text draws /over/ object.
        //
        glDisable(GL_DEPTH_TEST);
        {
            const char *p;
            gl_font(1, 12);
            glColor3f(1.0, 1.0, 1.0);
            glRasterPos3f(TOP);   p = "+ top";   gl_draw(p, strlen(p));
            glRasterPos3f(LEFT);  p = "+ left";  gl_draw(p, strlen(p));
            glRasterPos3f(RIGHT); p = "+ right"; gl_draw(p, strlen(p));
            glRasterPos3f(BACK);  p = "+ back";  gl_draw(p, strlen(p));
        }
        glEnable(GL_DEPTH_TEST);
        // Print rotangle value at fixed position at lower left
        char s[40];
        sprintf(s, "ROT=%.2f", rotangle);
        glLoadIdentity(); glRasterPos2f(-3,-2); gl_draw(s, strlen(s));
    }
    static void Timer_CB(void *userdata) {
        MyGlWindow *o = (MyGlWindow*)userdata;
        o->rotangle += 1.0;
        o->redraw();
        Fl::repeat_timeout(1.0/24.0, Timer_CB, userdata);       // 24fps
    }
public:
    // CONSTRUCTOR
    MyGlWindow(int X,int Y,int W,int H,const char*L=0) : Fl_Gl_Window(X,Y,W,H,L) {
        rotangle = 0;
        Fl::add_timeout(3.0, Timer_CB, (void*)this);       // wait 3 secs before animation begins
    }
};
/////////////////////////////////////////////////////////////////////////////////
// Next set up the translucent dialog window
class translucent_dialog : public Fl_Double_Window
{
public:

    translucent_dialog(int X, int Y, int W, int H, const char *L = 0) :
        Fl_Double_Window(X, Y, W, H, L),
        win_alpha_(255)
    {
        clear_border();
        box(FL_FLAT_BOX);
    } // constructor

    void set_alpha(int new_alpha)
    {
        if (new_alpha < 0)
        {
            win_alpha_ = 0;
        }
        else if (new_alpha > 255)
        {
            win_alpha_ = 255;
        }
        else
        {
            win_alpha_ = new_alpha;
        }

#if defined (_WIN32)
        HWND hwnd = fl_xid(this);
        LONG_PTR exstyle = GetWindowLongPtr(hwnd, GWL_EXSTYLE);
        if (!(exstyle & WS_EX_LAYERED))
        {
            SetWindowLongPtr(hwnd, GWL_EXSTYLE, exstyle | WS_EX_LAYERED);
        }
        SetLayeredWindowAttributes(hwnd, 0, BYTE(win_alpha_), LWA_ALPHA);
//        SetLayeredWindowAttributes(hwnd, RGB(0, 0, 0), 0, LWA_COLORKEY);
#elif defined(__APPLE__)
        double alpha = (double)win_alpha_ / 255.0;
        setWindowTransparency(this, alpha); // defined in transp_cocoa.mm
#else
        double alpha = (double)win_alpha_ / 255.0;
        uint32_t cardinal_alpha = (uint32_t)(UINT32_MAX * alpha);
        Atom atom = XInternAtom(fl_display, "_NET_WM_WINDOW_OPACITY", False);
        XChangeProperty(fl_display, fl_xid(this),
                        atom, XA_CARDINAL, 32,
                        PropModeReplace, (unsigned char *)&cardinal_alpha, 1);
#endif
    } // set_alpha

    int current_alpha (void)
    {
        return  win_alpha_;
    } // current_alpha

private:
    int win_alpha_;
}; // class translucent_dialog

/////////////////////////////////////////////////////////////////////////////////
static Fl_Window *main_win = NULL;
static translucent_dialog *t_dialog = NULL;

/////////////////////////////////////////////////////////////////////////////////
static void cb_menu_bt(Fl_Button *, void *)
{
    t_dialog->position(main_win->x_root() + 200, main_win->y_root() + 90);
    t_dialog->show();
    t_dialog->set_alpha(127);
} // cb_menu_bt

/////////////////////////////////////////////////////////////////////////////////
static void cb_hide_bt(Fl_Button *, void *)
{
    t_dialog->hide();
} // cb_hide_bt

/////////////////////////////////////////////////////////////////////////////////
static void cb_quit_bt(Fl_Button *, void *)
{
    // close all windows and exit
    if (t_dialog) t_dialog->hide();
    if (main_win) main_win->hide();
} // cb_quit_bt

/////////////////////////////////////////////////////////////////////////////////// MAIN
int main(int argc, char **argv)
{
    main_win = new  Fl_Window (640, 480, "Menu over GL scene test");
    main_win->begin();

    MyGlWindow mygl(10, 10,  main_win->w()-20,  main_win->h()-90);
    mygl.end();

    Fl_Button *menu_bt = new Fl_Button(10, 430, 75, 35, "Menu");
    menu_bt->callback((Fl_Callback *)cb_menu_bt);

    Fl_Button *quit_bt = new Fl_Button(555, 430, 75, 35, "Exit");
    quit_bt->callback((Fl_Callback *)cb_quit_bt);

    main_win->end();
    main_win->show(argc, argv);

    // Create the translucent dialog
    t_dialog = new translucent_dialog (main_win->x_root() + 200, main_win->y_root() + 90, 240, 300);
    t_dialog->begin();
    Fl_Choice *td_choice = new Fl_Choice(60, 25, 90, 25, "Test ");
    td_choice->down_box(FL_BORDER_BOX);
    td_choice->add("Line 1");
    td_choice->add("Line 2");
    td_choice->add("Line 3");
    td_choice->add("Line 4");
    td_choice->add("Line 5");

    Fl_Button *bt = new Fl_Button(60, 60, 75, 35, "Test");
    bt = new Fl_Button(60, 95, 75, 35, "Test");
    bt = new Fl_Button(60, 130, 75, 35, "Test");

    Fl_Button *hide_bt = new Fl_Button(155, 255, 75, 35, "Hide");
    hide_bt->callback((Fl_Callback *)cb_hide_bt);
    t_dialog->end();

    return Fl::run();
} // main

// end of file //

Also need to have an implementation of setWindowTransparency(this, alpha); for macOS, it looks like this:

#ifdef __APPLE__
/* The OSX Cocoa stub to do window transparency... */

#include <FL/x.H>
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>

#import <Cocoa/Cocoa.h>

void setWindowTransparency(Fl_Window *w, double alpha)
{
    [fl_xid(w) setAlphaValue:alpha];
}
#endif // (__APPLE__)

/* end of file */

 

[Manolo]

Le mercredi 14 septembre 2022 à 21:41:51 UTC+2, Gonzalo a écrit :

> El 13 sep. 2022, a las 06:28, Manolo  escribió:
>
> @Gonzalo: I realize now my proposal was wrong.
> The good solution is not to use a transparent GL2 window but a transparent normal window,
> see attached example program which builds upon OpenGL3test.cxx :
>

That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).

I attach a new attempt to allow transparent colors. It uses the recent changes to FLTK 1.4 committed to git.

Unfortunately it works only partially under macOS because transparency starts correctly but then disappears,  for a reason that remains unclear to me.

The code is meant to be cross platform with a macOS version and a version for other platforms.

It works well under the wayland platform.

But the transition between GL3-style and GL2-style drawing that works under Wayland fails under X11.

Did you succeed in doing that? If yes, can you, please, share your procedure?

[Gonzalo Garramuno]

> El 15 sep. 2022, a las 13:45, Manolo <manol...@gmail.com> escribió:
>
>
>
> Le mercredi 14 septembre 2022 à 21:41:51 UTC+2, Gonzalo a écrit :
>
>
> > El 13 sep. 2022, a las 06:28, Manolo escribió:
> >
> > @Gonzalo: I realize now my proposal was wrong.
> > The good solution is not to use a transparent GL2 window but a transparent normal window,
> > see attached example program which builds upon OpenGL3test.cxx :
> >
>
> That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).
>
> I attach a new attempt to allow transparent colors. It uses the recent changes to FLTK 1.4 committed to git.
> Unfortunately it works only partially under macOS because transparency starts correctly but then disappears, for a reason that remains unclear to me.

I tried it on macOS and could not make it fail. It was always semi transparent. What triggers the disappearance of the transparency?

> The code is meant to be cross platform with a macOS version and a version for other platforms.
> It works well under the wayland platform.
> But the transition between GL3-style and GL2-style drawing that works under Wayland fails under X11.

That’s too bad.

> Did you succeed in doing that? If yes, can you, please, share your procedure?
>

No. I am currently working on macOS and will try the other platforms later.

—
Gonzalo Garramuno
ggar...@gmail.com

[Gonzalo Garramuno]

> El 15 sep. 2022, a las 10:39, imacarthur <imaca...@gmail.com> escribió:
>
> On Wednesday, 14 September 2022 at 20:41:51 UTC+1 Gonzalo wrote:
>
> That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).
>
> OK, so in looking for some old code to answer a question on fltk.general (Hi Gonzalo...) I found another bit of code I had.
>
> If the question is about drawing a translucent FL window over a GL surface, I have code for this... Here's an example - it's GL2, but should Just Work.

No. The question was about drawing translucent widgets (buttons, text inputs, etc) over GL3 window. With GL2 it is easy, as calling the base Fl_Gl_Window::draw() at the end in the virtual draw function of the GL window does it.

Your code turns the a normal fltk window semi transparent.

—
Gonzalo Garramuno
ggar...@gmail.com

[Manolo]

Le vendredi 16 septembre 2022 à 00:04:43 UTC+2, Gonzalo a écrit :

> El 15 sep. 2022, a las 13:45, Manolo  escribió:
>
>
>
> Le mercredi 14 septembre 2022 à 21:41:51 UTC+2, Gonzalo a écrit :
>
>
> > El 13 sep. 2022, a las 06:28, Manolo escribió:
> >
> > @Gonzalo: I realize now my proposal was wrong.
> > The good solution is not to use a transparent GL2 window but a transparent normal window,
> > see attached example program which builds upon OpenGL3test.cxx :
> >
>
> That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).
>
> I attach a new attempt to allow transparent colors. It uses the recent changes to FLTK 1.4 committed to git.
> Unfortunately it works only partially under macOS because transparency starts correctly but then disappears, for a reason that remains unclear to me.

I tried it on macOS and could not make it fail. It was always semi transparent. What triggers the disappearance of the transparency?

What I see is:

- run the program, the button's background is colored red blended to the underlying blue color; that's good;

- hide the program (cmd-H) , show it again: the button is colored pure red; that's bad.

I run here macOS Ventura 13.0 public beta.  It might be a Ventura bug?

> The code is meant to be cross platform with a macOS version and a version for other platforms.
> It works well under the wayland platform.
> But the transition between GL3-style and GL2-style drawing that works under Wayland fails under X11.

That’s too bad.

> Did you succeed in doing that? If yes, can you, please, share your procedure?
>

No. I am currently working on macOS and will try the other platforms later.

You had written in this thread on 9 sept :

"On Linux and Windows this works, but on macOS, as Manolo said, it does not, as it does not allow
mixing OpenGL2 and OpenGL3+ calls. "

I interpreted that meaning you solved how to combine GL3 + GL2 under Linux and Windows.

[Gonzalo Garramuno]

> El 16 sep. 2022, a las 04:17, Manolo <manol...@gmail.com> escribió:
>
>
>
> Le vendredi 16 septembre 2022 à 00:04:43 UTC+2, Gonzalo a écrit :
>
>
> > El 15 sep. 2022, a las 13:45, Manolo escribió:
> >
> >
> >
> > Le mercredi 14 septembre 2022 à 21:41:51 UTC+2, Gonzalo a écrit :
> >
> >
> > > El 13 sep. 2022, a las 06:28, Manolo escribió:
> > >
> > > @Gonzalo: I realize now my proposal was wrong.
> > > The good solution is not to use a transparent GL2 window but a transparent normal window,
> > > see attached example program which builds upon OpenGL3test.cxx :
> > >
> >
> > That *almost* works. What is missing is giving the button a transparent or semi-transparent color, like in the cube.cxx demo. I would need that, or a FL_STENCIL on the window, so I can implement drawing in the window (with erasing with the stencil).
> >
> > I attach a new attempt to allow transparent colors. It uses the recent changes to FLTK 1.4 committed to git.
> > Unfortunately it works only partially under macOS because transparency starts correctly but then disappears, for a reason that remains unclear to me.
>
> I tried it on macOS and could not make it fail. It was always semi transparent. What triggers the disappearance of the transparency?
>
> What I see is:
> - run the program, the button's background is colored red blended to the underlying blue color; that's good;
> - hide the program (cmd-H) , show it again: the button is colored pure red; that's bad.
>
> I run here macOS Ventura 13.0 public beta. It might be a Ventura bug?
>

No, if It is a bug it’s present on Monterrey too.

>
> You had written in this thread on 9 sept :
> "On Linux and Windows this works, but on macOS, as Manolo said, it does not, as it does not allow
> mixing OpenGL2 and OpenGL3+ calls. "
> I interpreted that meaning you solved how to combine GL3 + GL2 under Linux and Windows.
>

Sorry. I misspoke. I was just repeating what you mentioned about GL3/2 compatibility without having tried it myself.

You had written on the 8th of September:

"Notice this restriction is macOS-specific. The other 3 platforms allow mixing."

—
Gonzalo Garramuno
ggar...@gmail.com

[imm]

On Thu, 15 Sept 2022 at 23:09, Gonzalo wrote:
>
>
> No. The question was about drawing translucent widgets (buttons, text inputs, etc) over GL3 window. With GL2 it is easy, as calling the base Fl_Gl_Window::draw() at the end in the virtual draw function of the GL window does it.
>
> Your code turns the a normal fltk window semi transparent.

Indeed it does, but that's "functionally equivalent" here, I would
suggest - I have used this technique to position translucent controls
over a variety of other windows, including over GL2 (as shown in the
example) and GL3 windows, and it has always Just Worked.

So whilst it may be a departure from using GL to render the FLTK
controls in the GL window, it can produce an effect that looks very
similar to the end user, and appears to be pretty portable across
systems (so far, at any rate!)

[imm]

On Fri, 16 Sept 2022 at 09:31, Gonzalo wrote:
> > "On Linux and Windows this works, but on macOS, as Manolo said, it does not, as it does not allow
> > mixing OpenGL2 and OpenGL3+ calls. "
> > I interpreted that meaning you solved how to combine GL3 + GL2 under Linux and Windows.
> >
>
> Sorry. I misspoke. I was just repeating what you mentioned about GL3/2 compatibility without having tried it myself.

I have a sort of toy 3D viewer I made ages ago that basically plots
the scene twice with colour filtering for red/cyan anaglyph glasses.
Works surprisingly well, and uses a weird mix of GL2 (to render my old
OBJ based models) and GL3 to do the colour filtering and the
anti-aliased textures and so on.
Anyway, that all works fine on WinXX and X11.

Oh, hold on! I just remembered, this code also works on my old macOS
box too (which is IIRC 10.13). When did Apple break the GL2/GL3
compatibility, because it seems to work fine on my old Mac...
It is possible I am "getting away with it" because the drawing isn't
mixed in a single context, there's some textures drawn using GL2 that
are then passed to a couple of GL3 rendering stages...

[Manolo]

Le vendredi 16 septembre 2022 à 10:31:56 UTC+2, Gonzalo a écrit :

> You had written in this thread on 9 sept :
> "On Linux and Windows this works, but on macOS, as Manolo said, it does not, as it does not allow
> mixing OpenGL2 and OpenGL3+ calls. "
> I interpreted that meaning you solved how to combine GL3 + GL2 under Linux and Windows.
>

Sorry. I misspoke. I was just repeating what you mentioned about GL3/2 compatibility without having tried it myself.

You had written on the 8th of September:
"Notice this restriction is macOS-specific. The other 3 platforms allow mixing."

 Let's be very explicit to avoid misunderstandings on all sides.

macOS forbids in principle to use GL2 function calls in a GL3 context.

If you do such calls, the program either crashes or does not perfom the requested operation.

The other platforms allow, in principle, to combine GL3 and GL2 calls, that's called a

compatibility context in GL3 parlance. The question of how, in practice, to call these

two sets of functions in a way that makes sense to GL remains. I don't know the answer.
I just observed that the procedure followed in OpenGL3test.cxx works under Wayland,

but fails under X11. Any suggestion welcome.

[Manolo]

Le vendredi 16 septembre 2022 à 11:38:22 UTC+2, imacarthur a écrit :

Oh, hold on! I just remembered, this code also works on my old macOS
box too (which is IIRC 10.13). When did Apple break the GL2/GL3
compatibility, because it seems to work fine on my old Mac...
It is possible I am "getting away with it" because the drawing isn't
mixed in a single context, there's some textures drawn using GL2 that
are then passed to a couple of GL3 rendering stages...

Disclaimer: I ignore totally how GL2 or GL3 are supposed to be programmed.

My understanding is that on day one macOS begun to support GL3, it did so

in an exclusive mode: either GL2 or GL3, never both.

@Ian : do you think your technique to draw part of a scene with GL2 and use

the result in GL3 or vice versa could be used to support adding, under macOS,

FLTK widgets (which are drawn by Fl_OpenGL_Graphics_Driver using GL2) to

a GL3-based Fl_Gl_Window ? Do you have any hint about how to

draw first with GL3 and second with GL2 to the same Fl_Gl_Window under X11

and Windows? As written in the previous post, I believe to know how to do that

under Wayland, but that fails under X11.

[imacarthur]

On Friday, 16 September 2022 at 14:09:07 UTC+1 Manolo wrote:

@Ian : do you think your technique to draw part of a scene with GL2 and use

the result in GL3 or vice versa could be used to support adding, under macOS,

FLTK widgets (which are drawn by Fl_OpenGL_Graphics_Driver using GL2) to

a GL3-based Fl_Gl_Window ? Do you have any hint about how to

draw first with GL3 and second with GL2 to the same Fl_Gl_Window under X11

and Windows? As written in the previous post, I believe to know how to do that

under Wayland, but that fails under X11.

So... I've had a look at my code, in an attempt to understand what it actually does (it's old, and was only written as a hack to try and view some old OBJ models in a stereoscopic way...)

Frankly, I have no idea why it works, but it appears to, on Win32 and macOS, and I remember it working on X11 at the time (have not checked today.)

So, the first thing is that the only Mac I have now is old, running 10.13 or so IIRC, so not all that current, and can not run any macOS more recent.

Next, all platforms (including OSX) seems to be using GLEW to access the "higher" API levels. (I might be wrong about this though!)

The OBJ models are rendered with some old code that uses GL1-style methods, these are written into buffers, which are then read into various other textures to apply the (anaglyphic) colour filtering and anti-aliasing, before getting merged together in yet more textures and rendered to the display. These later stages are using later GL API to do their magic, but I'm looking at the code and I do not understand what I did, nor have any idea why... (I also can't see why I needed so many intermediate buffers to get to the  end result.)

Anyway: The end result is that a picture does appear, and when viewed through the anaglyph glasses the stereoscopic effect works (more or less, as well as anaglyphic rendering, anyway) but...

I suspect the crux is that the GL-1.x and GL-3 stuff never actually happens in the same context (my recollection was that it did, that appears not to be true) - the GL-1.x stuff is effectively written out to a pixelmap and then read in by the GL-3 code.

Anyway, what I have is a mess and may only work by random chance!

It certainly does not look like something we should strive to reproduce.

 

[Manolo]

I've now found how to add widgets to a GL3-using Fl_Gl_Window in a cross-platform way.

The attached program is an example that runs on all 4 platforms (Windows, X11, Wayland, macOS) with the last git code

of FLTK 1.4 where a partially transparent button is laid over a GL3 scene.

With those platforms that allow the so-called compatibility profile, the key is to call

glUseProgram(0);

between the end of the GL3  and the beginning of the GL2 drawing parts.

It has also been necessary to change the X11 driver code  to have it ask for a compatibility profile.

macOS does not provide the compatibility profile. The solution is to create an additional Fl_Gl_Window above the window

containing the GL3 scene, to put FLTK widgets therein, and to give it a transparent background.

[Manolo]

The FLTK git repo now contains (89f9671) cross-platform support for adding FLTK widgets

to an OpenGL3-using Fl_Gl_Window.

The FLTK doc will soon show a detailed explanation of how to do that :

https://fltk.gitlab.io/fltk/opengl.html#opengl3

[Manolo]

Le dimanche 25 septembre 2022 à 17:04:19 UTC+2, Manolo a écrit :

The FLTK git repo now contains (89f9671) cross-platform support for adding FLTK widgets

to an OpenGL3-using Fl_Gl_Window.

That commit has been completed by a newer one (59fc60e) that removes the need

for platform-specific source code in apps that add FLTK widgets to OpenGL3 windows.

Demo program examples/OpenGL3test.cxx shows how to add an FLTK button to

an OpenGL3 window.

[imacarthur]

Hmm, not sure that works on my ancient Mac; I have 

ian$ git log -n1

commit 3225afaeecc1a1f0a54cab6f60be485a0352606c (HEAD -> master, origin/master, origin/HEAD)

Author: ManoloFLTK <41016272+...@users.noreply.github.com>

Date:   Tue Sep 27 16:51:35 2022 +0200

    Remove use of class Fl_Window_Driver inside libfltk_gl

And when I run  examples/OpenGL3test I get the GL pane filled with solid red, and a translucent button above it (not the expected square with the rainbow gradient.)

If I toggle double/single buffer, the gradient square appears and the button disappears.

In either case, if I click where I know the object to be the diagnostics printed suggest the widgets are present and responding normally, I simply can not see them.

GL_VERSION=4.1 ATI-1.68.25
Shading Language Version=4.10

on macOS High Sierra 10.13.6

[Manolo]

Ian: could you, please, comment out line #141 of file examples/OpenGL3test.cxx to obtain

    //Fl_Gl_Window::draw(); // Draw FLTK child widgets.

and report here whether the GL3 scene draws correctly after that change?

TIA.

[Ian MacArthur]

On 28 Sep 2022, at 07:10, Manolo wrote:
>
> Ian: could you, please, comment out line #141 of file examples/OpenGL3test.cxx to obtain
> //Fl_Gl_Window::draw(); // Draw FLTK child widgets.
> and report here whether the GL3 scene draws correctly after that change?
> TIA.

OK - that works “as normal”, though of course there is no button drawn now. The button is still there though, as I can “click” it if I know where to press.

Also, more info about the “broken” state: Previously I noted that toggling from double-buffered to single-buffered caused the gradient square to appear and hid the button.
Any subsequent toggling of that always shows the gradient square, in either double or single-buffer display, but transiently as the scene is redrawn on each toggle, I can see the button being shown and there is a substantial flickering, as if the whole scene were drawn "in red with a button", then redrawn with the gradient square...

[Manolo]

Ian: would you, please, try with this patch (after a git pull) ?

patch -p1 < switch2GL1attempt.patch.txt

[Ian MacArthur]

On 28 Sep 2022, at 09:15, Manolo wrote:
>
> Ian: would you, please, try with this patch (after a git pull) ?
> patch -p1 < switch2GL1attempt.patch.txt
>

Different - but not the whole story...

The GL panel now shows the gradient square from start, but the button is invisible.
The button is “there” as I can click it, but it does not show on the screen...

It’s possible this Mac is just Too Old, I suppose, so maybe not worth pursuing?
Though I do not know how many other “old” Macs are still out there, could be a fair few I suppose...

[imacarthur]

Sorry, it gets worse...

For other reasons I was setting up a test PC with Win11, getting the tools installed and so on, and as a check I built fltk-1.4 to verify the toolchain (mingw) was OK.

All built OK and works - except for OpenGL3test.exe which segfaults very shortly after it starts up.

Thinking this might be a Win11 weirdness (since this has worked on Win10 for me previously) I checked on a Win10 box - there, OpenGL3test.exe ran OK, until I did a pull and rebuild, thereafter it also crashes.

This was after a git pull to:

commit 7d58e2385452b8373448e3f91013a8cda39c7aa3
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date:   Wed Sep 28 08:23:36 2022 +0200

    macOS: add necessary setWantsBestResolutionOpenGLSurface:YES message.

But (foolishly) I don't know what commit the branch was at when it worked, unfortunately, but should be very recent. Time permitting I'll bisect but I have some stuff to deal with elsewhere first...

 

[Manolo Gouy]

I’ve

> Le 28 sept. 2022 à 13:05, imacarthur <imaca...@gmail.com> a écrit :
>
>
> Sorry, it gets worse...
> For other reasons I was setting up a test PC with Win11, getting the tools installed and so on, and as a check I built fltk-1.4 to verify the toolchain (mingw) was OK.
>
> All built OK and works - except for OpenGL3test.exe which segfaults very shortly after it starts up.

I used successfully the new code here under Win11 (arm64). So I would believe a clean re-build is necessary
because there were changes to class layouts.

[imm]

On Wed, 28 Sept 2022 at 13:37, Manolo Gouy wrote:
>
> I used successfully the new code here under Win11 (arm64). So I would believe a clean re-build is necessary
> because there were changes to class layouts.
>

I don't think it is just a build issue: I've been doing a make clean
before each make, but to check I regenerated the build folder each
time and got the same result.

For me, on Win10 and Win11, both x86_64, I find that
59fc60ea4cb8db6ee43a1ac37cd4bbbefcb87faa and anything after it fails
to run OpenGL3test.exe. Other tests and examples seem to be OK.

Similarly 2ffd4e4f1af16b17a286ff354603a717f5d828a5 and earlier are
more or less OK.[1]

I don't think it is a driver issue either, as the Win10 box has an
Nvidia GPU (and a built-in Intel GPU) and the Win11 box is AMD.


[1] The working version is still a bit glitchy, in that when I switch
from double to single-buffered mode, whilst everything draws "OK" the
button label disappears, and does not subsequently re-appear.

[Manolo]

Ian: please git pull . The new code should work under macOS 10.10 because I see it OK

under 10.9 here.

For WIN32, I'm puzzled cause it runs here. A debug, or a traceback at the crash point would help.

[imm]

On Wed, 28 Sept 2022 at 16:23, Manolo wrote:
>
> Ian: please git pull . The new code should work under macOS 10.10 because I see it OK
> under 10.9 here.
>

OK, but it will be later, as I'm away from the Mac just now...

> For WIN32, I'm puzzled cause it runs here. A debug, or a traceback at the crash point would help.
>

What tool are you building with?
I have mingw, 32-bit - but I'd guess for Win11 on ARM you are using
the MSVC tools?

I'll try and see if I can get any more insight... might mean doing a
debug build though!

[Albrecht Schlosser]

On 9/28/22 13:05 imacarthur wrote:

This was after a git pull to:

commit 7d58e2385452b8373448e3f91013a8cda39c7aa3
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date:   Wed Sep 28 08:23:36 2022 +0200

    macOS: add necessary setWantsBestResolutionOpenGLSurface:YES message.

But (foolishly) I don't know what commit the branch was at when it worked, unfortunately, but should be very recent.

FWIW: `git reflog` will likely give you the answer - once you learn how to interpret the output. It tells you the git commits you recently "visited".

[imm]

On Wed, 28 Sept 2022 at 16:26, imm wrote:
>
> > For WIN32, I'm puzzled cause it runs here. A debug, or a traceback at the crash point would help.
> >
> What tool are you building with?
> I have mingw, 32-bit - but I'd guess for Win11 on ARM you are using
> the MSVC tools?
>
> I'll try and see if I can get any more insight... might mean doing a
> debug build though!

Well that was profoundly unhelpful: Here is the gdb log from the crash

Reading symbols from
d:\Tools\Ian\fltk-1.4\build\bin\examples\OpenGL3test.exe...done.
(gdb) r
Starting program: d:\Tools\Ian\fltk-1.4\build/bin/examples/OpenGL3test.exe
[New Thread 8612.0x2ac0]
[New Thread 8612.0xaec]
[New Thread 8612.0x2bfc]
[New Thread 8612.0x2790]
[New Thread 8612.0x2008]
[New Thread 8612.0x29d0]
[New Thread 8612.0x2918]
[New Thread 8612.0x287c]

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x01800000 in ?? ()
#2 0x00000000 in ?? ()
(gdb)

Wherever it is segfaulting, it doesn't seem to have enough context to
be able to say where it went awry, even...It appears the frame is zero
at that point.

Also, Albrecht - thanks for the git reflog tip, I'll try that next
time, see if it makes sense to me. At present it shows a lot of churn,
but that's from me trying to bisect the crash of course.

Anybody - does this OpenGL3test.exe work on WinXX x86-64 for you or
not? Is it only me that sees it crashing?

[imm]

On Wed, 28 Sept 2022 at 16:44, imm wrote:
> Also, Albrecht - thanks for the git reflog tip, I'll try that next
> time, see if it makes sense to me. At present it shows a lot of churn,
> but that's from me trying to bisect the crash of course.
>

OK, I have made sense of the reflog churn...

The commit I had been using was 89f9671b406d1d2ac0377ef90d44ebfa7a92150e
This works, apart from the button label disappearing when flipping the buffers.

The commit 59fc60ea4cb8db6ee43a1ac37cd4bbbefcb87faa is where it breaks for me.

[Albrecht Schlosser]

On 9/28/22 17:44 imm wrote:

Also, Albrecht - thanks for the git reflog tip, I'll try that next
time, see if it makes sense to me. At present it shows a lot of churn,
but that's from me trying to bisect the crash of course.

Welcome.

Anybody - does this OpenGL3test.exe work on WinXX x86-64 for you or
not? Is it only me that sees it crashing?

I tried it in my Virtualbox VM and - not surprising (known issue) - I don't have OpenGL V3 support:

```
Using GLEW 2.2.0
GL_VERSION=1.1.0

This platform does not support OpenGL V3
```

Sorry, I can't help (can't run a native Windows system now).

[imm]

On Wed, 28 Sept 2022 at 17:06, imm wrote:
>
> OK, I have made sense of the reflog churn...
>
> The commit I had been using was 89f9671b406d1d2ac0377ef90d44ebfa7a92150e
> This works, apart from the button label disappearing when flipping the buffers.
>
> The commit 59fc60ea4cb8db6ee43a1ac37cd4bbbefcb87faa is where it breaks for me.

This is perhaps significant:- I'd been testing with 32-bit builds on
both Win10 and Win11 (the Win11 box I'm setting up is for a 32-bit
build target, though is itself 64-bit of course.)

But I just built 283184a09a360724a61b9e256c16f799a73cf405 (head of
master at time of testing) with mingw in 64-bit mode, and that runs OK
and does not crash, so the issue may be a data or pointer size issue,
or similar?

The label for the button still disappears on toggling the buffer mode,
but at least it runs and is visible!

[Manolo]

I'm using mingw64 and run the exe on a true PC, because my virtual machine doesn't give OpenGL3.

I may be able to try with mingw32 too.

[Ian MacArthur]

On 28 Sep 2022, at 16:26, imm wrote:
>
> On Wed, 28 Sept 2022 at 16:23, Manolo wrote:
>>
>> Ian: please git pull . The new code should work under macOS 10.10 because I see it OK
>> under 10.9 here.
>>
>
> OK, but it will be later, as I'm away from the Mac just now...

OK, pulled 7d58e2385452b8373448e3f91013a8cda39c7aa3 and created a new build folder.
All compiled OK, but when run I get the red GL panel with button, no gradient square.

Toggling from double to single-buffered and back, I do then see the gradient square, but as before the button disappears.
Other samples seem to be working just fine.

I do not know what can be happening of this works OK under 10.9 for you...

[Ian MacArthur]

On 28 Sep 2022, at 21:38, Ian MacArthur wrote:
>
> On 28 Sep 2022, at 16:26, imm wrote:
>>
>> On Wed, 28 Sept 2022 at 16:23, Manolo wrote:
>>>
>>> Ian: please git pull . The new code should work under macOS 10.10 because I see it OK
>>> under 10.9 here.
>>>
>>
>> OK, but it will be later, as I'm away from the Mac just now...
>
> OK, pulled 7d58e2385452b8373448e3f91013a8cda39c7aa3 and created a new build folder.
> All compiled OK, but when run I get the red GL panel with button, no gradient square.

Sorry - my bad.
Pulled the wrong version.
Updated to 283184a09a360724a61b9e256c16f799a73cf405 and now it does work as intended.
Better than the Windows version, even, because the label on the button survives toggling between double and single buffered...

[Manolo]

Ian: could you, please, share your 32-bit libglew.a ? I have only the 64-bit version of it. TIA.

[Manolo]

Le mercredi 28 septembre 2022 à 23:16:28 UTC+2, Manolo a écrit :

Ian: could you, please, share your 32-bit libglew.a ? I have only the 64-bit version of it. TIA.

Never mind. I've found it after a simple google search.

[Manolo]

With the last commit (da66e21), the addition of FLTK widgets to an OpenGL 3-based Fl_Gl_Window

works in my hands accross all platforms and OS versions, including Windows 10-32-bit and macOS 10.9.

Toggle betwen double and single buffer modes also works.

[imacarthur]

Sorry Manolo - I didn't see this in time. It was "late" when you sent it, too late for me at any rate. It must have been "late + 1" for you, too, I guess.

FWIW, I usually just build my own - though the Makefile they provide doesn't actually work for mingw (it builds the DLL OK, but makes a static lib that is incomplete) but the tweaks needed to actually produce a valid static lib are trivial.

This is a long standing issue that they appear uninterested in fixing, so I just roll my own.

If it's useful (though I suspect not now, from your later post) I can send you the libs I have in case there's something weird going on there.

[imacarthur]

OK - this commit seems to work - mostly. My macOS and 64-bit Win builds are now good.

32-bit Win still crashes for me.

I assumed that was some weirdness in my messed-up mingw configuration (it often is!) but possibly not this time.

Since I now (coincidentally) have a working 32-bit MSVC build, I fired that off and it also fails in the same way. 

Since I'm running to from the IDE, MSVC reports this is because:

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.  This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

This is in the method (the debugger flags that exception at the end of this method):

void Fl_Gl_Window_Driver::switch_to_GL1() {
  if (!glUseProgram_f) {
    glUseProgram_f = (glUseProgram_type)GetProcAddress("glUseProgram");
  }
  glGetIntegerv(GL_CURRENT_PROGRAM, &current_prog);
  // Switch from GL3-style to GL1-style drawing;
  // good under Windows, X11 and Wayland; not appropriate under macOS.
  // suggested by https://stackoverflow.com/questions/22293870/mixing-fixed-function-pipeline-and-programmable-pipeline-in-opengl
  if (current_prog) glUseProgram_f(0);
}

The GLEW lib I'm using for this test was built with the same MSVC IDE, so I assume it is compatible here.

TBH I have no solid idea what that error message is actually telling us happened here!

Clearly, whatever it is, it works fine on other platforms...

[imacarthur]

On Friday, 30 September 2022 at 12:45:13 UTC+1 imacarthur wrote:

TBH I have no solid idea what that error message is actually telling us happened here!

Clearly, whatever it is, it works fine on other platforms...

Staring at this a bit, I assume the issue is that (under 32-bit Windows) we're invoking the function pointer  glUseProgram_f() with the wrong calling convention (given that Windows seems to have several calling conventions.)

But... I'm not sure that we are, it kinda looks OK.

Don't know.

[imm]

On Fri, 30 Sept 2022 at 12:56, imacarthur <imaca...@gmail.com> wrote:
>
>
> Staring at this a bit, I assume the issue is that (under 32-bit Windows) we're invoking the function pointer glUseProgram_f() with the wrong calling convention (given that Windows seems to have several calling conventions.)
>
> But... I'm not sure that we are, it kinda looks OK.
> Don't know.

Seems to be a calling convention thing after all.
Explicitly changing the typedef for glUseProgram_type in
Fl_Gl_Window_Driver.H to become either of:

typedef void(__stdcall *glUseProgram_type)(GLint);

or

typedef void(APIENTRY *glUseProgram_type)(GLint);

Works for me, and the 32-bit mingw and (32-bit) MSVC builds no longer
segfault, indeed they now work correctly.
I think (but am not sure!) that the second form (the APIENTRY format)
is the more "portable" option.

But in either case we'll need something clever around that typedef as
setting APIENTRY is *not* going to be correct on macOS or X11!

[Manolo]

Le vendredi 30 septembre 2022 à 15:17:25 UTC+2, imacarthur a écrit :

Seems to be a calling convention thing after all.
Explicitly changing the typedef for glUseProgram_type in
Fl_Gl_Window_Driver.H to become either of:

typedef void(__stdcall *glUseProgram_type)(GLint);

or

typedef void(APIENTRY *glUseProgram_type)(GLint);

My bad. I have (again) forgotten that WINAPI is mandatory with pointer to functions

under Windows.

The problem should be fixed with commit 4f6965d.

@Ian: Do you see it fixed too?

 

[imm]

On Fri, 30 Sept 2022 at 14:58, Manolo wrote:
>
> The problem should be fixed with commit 4f6965d.
> @Ian: Do you see it fixed too?

Seems good, tested with 32-bit builds (minw and MSVC) and both were fine.
Also tested 64-bit, but it worked anyway!

Cheers...