Using different GL contexts with an Fl_Gl_WIndow

[Ian MacArthur]

All,

Some questions about using OpenGL (which I do from time to time, but it is really *not* my strong suit…)

Has anyone got some tips, or better yet some examples, of using Fl_Gl_Window with GL contexts that were created via means other than the fltk built in provides?

In particular, I need to set some particular properties on the GL context to use some fancy modern features, and it looks like the “easiest” way to do this might be to create the GL context by “conventional” mean then attach it to the Fl_Gl_window…

Indeed, I find that on WIN32 hosts, the Fl_Gl_Window does not even implement FL_MULTISAMPLE (staring at the source a bit, it looks like maybe only GLX does implement FL_MULTISAMPLE - the WIN32 code does not, and I think the APPLE code doesn’t either, though I guess a lot of stuff is anti-aliased and such on OSX anyway, so maybe that has multisample by default? I do not know what I’m talking about here…)

Anyway… I imagine that I can (somehow) create my Fl_Gl_window, and create the GL context I want, then tie them together using the Fl_Gl_Window::context(…) methods.

But, I’d be keen on input from someone who actually knows what’s going on here!

Thanks,
—
Ian

[MacArthur, Ian (Selex ES, UK)]

Replying to my own post - or at least just adding some extra info.

I poked at this a bit over the weekend, and got some results that look the way I wanted; I did not use the Fl_Gl_Window::context(…); methods at all though.

Rather, what I did was set up an offscreen FBO that has a multisample renderbuffer (and depth buffer) attached and drew my geometry into that.

Then I blitted the resulting scene into a regular 2D texture attached to *another* FBO, messed about with that to do some post processing, then finally rendered that onto the screen (just draw the texture onto a screen-sized quad.)

Result looks fine, and did not require me to do anything to the Fl_Gl_Window context to work.

It also seems to run fast and smooth, at least on my Mac.
On my Win7 test box, it is very much clunkier. The Win7 box is pretty high-spec, so ought to be able to cope. It is very likely I am using the GL driver in a less than optimal way...!

Indeed, I'd still be interested in hearing from others who actually know how this is supposed to work.
And of course, I'd not advocate that anyone follow my pattern here, as I'm quite ready to believe there are better ways.

Cheers,
--
Ian



Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[mpercy]

I don't know if the following code snippet is useful, but it is what I am using on a Linux system to generate off-screen image data:

...

#include <GL/glx.h>

#include <X11/Xlib.h>
#include <X11/Xutil.h>

...

class myWindow : public Fl_Gl_Window
{
   void draw( void );
   ...
   uchar * _image;
   ...
 public:
   myWindow( int x, int y, int w, int h );
   void make_image( void );
   ...
};

...

void myWindow::make_image( void )
{

   Display     *dpy;
   GLXContext   ctx;
   Pixmap       x_pixmap;
   GLXPixmap    glx_pixmap;
   GLXFBConfig *fb_config;
   int          n_fb_configs;

   static int ctx_attr[] =
   {
      GLX_RENDER_TYPE, GLX_RGBA_BIT,
      GLX_DEPTH_SIZE, 24,
      GLX_DOUBLEBUFFER, False,
      GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT,
      GLX_BIND_TO_TEXTURE_RGBA_EXT, True,
      None
   };

   static int glxpix_attr[] =
   {
      GLX_TEXTURE_FORMAT_EXT, GLX_TEXTURE_FORMAT_RGBA_EXT,
      GLX_TEXTURE_TARGET_EXT, GLX_TEXTURE_2D_EXT,
      None
   };

   dpy = XOpenDisplay( 0 );

   fb_config = glXChooseFBConfig( dpy, 0, ctx_attr, &n_fb_configs );
   ctx = glXCreateNewContext( dpy, fb_config[0], GLX_RGBA_TYPE, NULL, True );

   x_pixmap = XCreatePixmap( dpy, DefaultRootWindow(dpy), _pW, _pH, 24 );

   glx_pixmap = glXCreatePixmap( dpy, fb_config[0], x_pixmap, glxpix_attr );

   glXMakeCurrent( dpy, glx_pixmap, ctx );

   draw();

   _image = new uchar[ _pW *_pH * 3 ];

   //glReadBuffer(GL_FRONT);
   glReadPixels( 0, 0, _pW, _pH, GL_RGB, GL_UNSIGNED_BYTE, _image );

   glXDestroyPixmap( dpy, glx_pixmap );
   XFreePixmap( dpy, x_pixmap );
   //glXDestroyContext(dpy, ctx);
}

...

I hope this helps.

MPercy

P.S.  I used _image as input for the generation of a PDF file via some non-FLTK code.

[Ian MacArthur]

On 11 Dec 2013, at 22:17, mpercy <moss...@gmail.com> wrote:

I hope this helps.

MPercy

P.S.  I used _image as input for the generation of a PDF file via some non-FLTK code.

Thanks for this.

I’d originally just wanted to make the “default” fltk GL window context support multi-sample so that I could anti-alias the view, but that was looking problematic...

In the end, I created a frame buffer object and attached a render buffer to the FBO, with multisample enabled on the render buffer, and drew everything into that context.

Then (and here it starts to look unnecessarily complex!) I blitted that into another FBO, this time attached to a GL_TEXTURE_2D texture buffer; this was because I wanted to mess about with the image data anyway though, so it worked out pretty well in practice.

I then blit the result into the regular fltk Gl_Window context and all is well; and surprisingly swift too, at least with a decent graphics card (doesn’t work under Mesa on a linux VM for example, but swift indeed on this Mac or the Win7 box.)

To get it to work on all 3 platforms, I ended up using GLEW to manage the GL extensions stuff, and that worked out really well. Never used GLEW or any GL Extension handler before, but the Khronos website suggested they were worth a shot, and indeed it worked well for me, so I’ll use it again for sure.

Cheers,

-- 

Ian