0
votes

I made a GUI-Framework with simple widgets like buttons, menus, lists, etc. It should run on modern PCs and on notebooks with on-board-graphic (which often only support GL 1.4). To achieve that I do the drawing in opengl 1.x ('immediate mode', display-lists, ...).

Now I have a few questions:

1) If I want to create a canvas-widget in which I draw with OpenGL 4.0+ functions/shaders, are there any problems? Could I mix OpenGL 4.0+ with OpenGL 1.x?

2) How do other OpenGL-GUI-APIs draw there stuff? Are they all using OpenGL 1.x to support as many PCs/Notebooks as possible? I know that the Blender-GUI uses OpenGL 1.x, but is this the best solution?

2
I want to mention that I use vertex/color/texture arrays for drawing not displaylists or 'immediate mode'.pwks

2 Answers

3
votes

If I want to create a canvas-widget in which I draw with OpenGL 4.0+ functions/shaders, are there any problems? Could I mix OpenGL 4.0+ with OpenGL 1.x?

Assuming you create an OpenGL 4.x compatibility context, yes. NVIDIA, AMD, and Intel support the compatibility profile (to the degree that Intel "supports" OpenGL at all).

How do other OpenGL-GUI-APIs draw there stuff? Are they all using OpenGL 1.x to support as many PCs/Notebooks as possible? I know that the Blender-GUI uses OpenGL 1.x, but is this the best solution?

Best is a subjective term. A lot of the OpenGL code (of any kind) you'll find online is old; one of the drawbacks of backwards compatibility is that people never feel the need to upgrade their old code or tutorials.

But there's nothing preventing you from rendering a GUI in core OpenGL 4.x. That's effectively how every D3D10 game renders its GUI, after all (since they don't have fixed-function anymore in D3D10).

1
votes

Could I mix OpenGL 4.0+ with OpenGL 1.x?

No. A OpenGL-1/2 compatibility profile is only available with OpenGL-3

Technically there is a compatibility profile available, actually. However I don't see any sane reason why somebody wanted to use it. If OpenGL-4 features are to be used, then so much of the internal structure of the program is to be changed, that compatibility profile no longer matters.

I know that the Blender-GUI uses OpenGL 1.x

There's currently a lot of development going on to make it OpenGL-4 compatible.

To achieve that I do the drawing in opengl 1.x ('immediate mode', display-lists, ...).

Both, display lists and immediate mode, are the huge roadblocks for you. Vertex Arrays have been available since OpenGL-1.1. It requires only minimal code to support OpenGL-4 once you've got Vertex Arrays set up. Basically all you need to do is replicate the fixed function pipeline by supplying the right shaders and associate the Vertex Arrays into the right attributes. For OpenGL-4 you also need a Vertex Array Object to hold the Vertex Array state.

As long as the shaders are not mandatory, i.e. you do only stuff that's also possible with fixed function, you can write this in a way that it supports the full range of OpenGL-1.1 to OpenGL-4.x with only very few runtime conditionals in your code.


Update due to comment:

I'm thinking about something like this: Let's assume a sourcefile guiGL.c

#if GLPATH==2
#define GLPREFIX(x) glpath2_#x
#elif GLPATH==3
#define GLPREFIX(x) glpath3_#x
#endif

void GLPREFIX(draw_button)
{
#if GLPATH==2
    /* OpenGL 2 code here */
#endif

#if GLPATH==3
    /* OpenGL 3 code here */
#endif

    /* common code here */

}

a dispatcher guiGLcommon.c

void draw_button()
{
    if(opengl_major_version <= 2) {
        glpath2_draw_button();
    } else {
        glpath3_draw_button();
    }
}

and a Makefile

guiGL_glpath2.o: guiGL.c
    $(CC) -DGLPATH=2 -o guiGL_glpath2.o -c guiGL.c

guiGL_glpath3.o: guiGL.c
    $(CC) -DGLPATH=3 -o guiGL_glpath2.o -c guiGL.c

guiGL.o: guiGLcommon.c 
    $(CC) -o guiGL.o -c guiGLcommon.c

# ...

target: ...
    $(CC) -o target guiGL.o guiGL_path2.o guiGL_path3.o ...