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?
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.
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).
> 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).
> 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?
> 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.
>
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."
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...
@Ian : do you think your technique to draw part of a scene with GL2 and usethe 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) toa GL3-based Fl_Gl_Window ? Do you have any hint about how todraw first with GL3 and second with GL2 to the same Fl_Gl_Window under X11and Windows? As written in the previous post, I believe to know how to do thatunder Wayland, but that fails under X11.
The FLTK git repo now contains (89f9671) cross-platform support for adding FLTK widgetsto an OpenGL3-using Fl_Gl_Window.
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
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.
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?
``` Using GLEW 2.2.0 GL_VERSION=1.1.0 This platform does not support OpenGL V3 ```
Ian: could you, please, share your 32-bit libglew.a ? I have only the 64-bit version of it. TIA.
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...
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);