STR #2944: Mac OS X Fl_Gl_Window bugs - all FLTK versions

STR #2944

Application:	FLTK Library
Status:	4 - Pending
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	2 - Specific to an operating system
Subsystem:	Core Library
Summary:	Mac OS X Fl_Gl_Window bugs - all FLTK versions
Version:	1.3.2
Created By:	lhquam
Assigned To:	greg.ercolano
Fix Version:	Unassigned
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

Trouble Report Comments:

Post Text

#1	lhquam 10:19 Apr 04, 2013

Patches for several Mac OS X Fl_Gl_Window bugs. I believe that these patches apply to ALL FLTK versions, with possible minor modifications to account for API differences. 1. Fl_Gl_Window::swap_buffers bug when a Gl_Window (simulated) overlay is used: glRasterPos is not properly set before calling glCopyPixels. This occurs when gl_draw(const char* str, int n) has been called to draw a string into the Gl_Window, which changed glRasterPos. 2. Fl_Gl_Window::make_current bug when the Gl_Window is inside nested Fl_Windows. The computation for the x and y values of the xywh array passed to aglSetInteger(context_, AGL_BUFFER_RECT, xywh) does not take this nesting into account, causing the Gl_Window drawing area to be incorrectly placed inside the main window. 3. Fl_Gl_Window::redraw_overlay unnecessarily redrawing everything rather than just the overlay. Apparently this was stale code that assumes that complete redraws were always needed on Mac OS X.

#2	greg.ercolano 09:06 Apr 05, 2013

Thanks for the patches! Can you supply a small compilable app that demonstrates the problem for (1) and (2)? Along the lines of e.g. http://seriss.com/people/erco/fltk/#OpenGlSimple Would like to verify the behavior described.

#3	lhquam 10:27 Apr 05, 2013

I have added files for two test programs that demonstrate the reported Gl_Window bugs.

#4	greg.ercolano 21:26 Apr 05, 2013

Assigning this STR to myself. Confirmed #2: Attaching rasterpos-fix-before-and-after-screenshot.jpg showing the problem/solution, and agree with the suggested fix to Fl_Gl_Window::make_current(). Since finding the window offset is now needed in at least two places in the code, will probably add a method to the Fl_Window base class that returns x/y offsets, and use that to implement the fix.

#5	greg.ercolano 23:51 Apr 05, 2013

To fix #2, I'm thinking the attached patch, rasterpos_bugfix.patch, might be a good way to implement the fix with code reuse in mind. This adds a find_offset() method to Fl_Widget.. essentially the same code you provided from Fl_mac.cxx, but made into a method so that both Fl_mac.cxx + Fl_Gl_Window.cxx can use it. Funny thing though, I *think* Fl_mac.cxx is completely unused code, a left over from the de-carbonization of FLTK. (verifying this with the other devs) In which case the code reuse issue might be moot. Still, it's probably useful to have this as a method; awaiting info from the other devs. Anyway, leaving this alternate patch suggestion to fix just #2 here, in case I get pulled off on other stuff and forget where I left off.

#6	greg.ercolano 12:01 Apr 07, 2013

Oops; named those attachments wrong: rasterpos-fix-before-and-after-screenshot.jpg rasterpos_bugfix.patch ..those should have been called 'nested-window' instead of 'rasterpos', as they are regarding the nested issue.

#7	greg.ercolano 12:17 Apr 07, 2013

Regarding #2: Confirmed problem with gl_draw()/glRasterPos() issue. Attaching gl_draw--before-and-after-screenshot.jpg which indeed shows the problem clearly using OP's one line mod to the gl_overlay demo (which just adds a gl_draw() to draw some text into the window) Looks like calling gl_draw() to draw some text in the GL window affects where the GL polys draw, and also messes up where the overlay lines are being drawn. On my mac, a default configure(1) ends up with HAVE_OVERLAY == 0, so I take it overlays are "emulated" as described in the docs, and is implemented here in the affected code. It does seem prudent as per the recommended patch to modify the swapbuffer() code to: save the matrix mode, jam an identity matrix into PROJECTION and MODELVIEW, and zero out the glRasterPos(), do the operation, pop the matrices, and restore the current matrixmode.. and all this only when overlays are present.

#8	greg.ercolano 12:20 Apr 07, 2013

And again oops; last message that says "Regarding #2" should read "Regarding #1". Pff, even had my coffee already. BTW, I'm being overly verbose here to cover my ass, as FLTK opengl internals is not my specialty, esp. the overlay plane stuff.. but I did do quite a bit of gl/opengl back in the day..

#9	greg.ercolano 11:27 Apr 08, 2013

OK; fixes applied to fltk 1.3.x svn current for these: Item #1: fixed in r9865 -- Apple specific overlay emulation issue with swapbuffer + gl rasterpos Item #2: fixed in r9866 -- Apple specific nested gl window issue Haven't gotten to investigating Item #3 yet.

#10	greg.ercolano 13:15 Apr 10, 2013

As a side note, in r9870, the new method suggest here to find the top-level window's offset relative to the current widget has been renamed to: top_window_offset(xoff,yoff)

#11	skunk 00:59 Nov 02, 2013

Hello to you both. I'm currently trying to get my Fl_Gl_Window_Group widget (see STR #2992) working on MacOS X, and am running into some of the same territory covered in this bug report. Greg, I wanted to ask you: In comment #7, you describe having Fl_Gl_Window::swap_buffers() save the matrix mode, blit the overlay, then restore the matrices. And I see the code doing that. Was there a reason why you didn't just create a separate context for that, like ortho_context in Fl_Gl_Window::flush()? I ask because OSX seems not to work quite right when you switch between two contexts on the same drawable---for me, one context works, the other does nothing. And on top of that, calling aglSetInteger() (inside fl_set_gl_context() and Fl_Gl_Window::make_current()) causes a premature buffer swap, for some reason. Does any of that sound like known issues for OpenGL on this platform?

#12	greg.ercolano 17:07 Oct 27, 2014

@Skunk (Comment #11): Have to admit I know little about this subject, so I don't think I can answer your question; perhaps someone else can, including the OP. As I mentioned in comment #8, afraid FLTK opengl internals is not my specialty, esp. the overlay plane stuff. I'm taking the OP's patch at face value that it solves the issue while changing as little as possible, using normal opengl methods I'm familiar with (as opposed to OSX specific calls that I'm not).

#13	greg.ercolano 17:10 Oct 27, 2014

Current state of this STR should probably not block 1.3.3 release; items #1 and #2 are bugs that have been addressed. And item #3, while still un-addressed, is I think a lesser issue (an optimization) that IMHO that shouldn't block 1.3.3. Therefore, I'm lowering the priority from 4 -> 3 so as to allow 1.3.3 to release with this STR still open.

#14	greg.ercolano 15:31 Apr 28, 2015

Hmm, OK, regarding the redraw_overlay() issue: with the patch applied I do get weird draw artifacts on some of the OSX platforms when I run test/gl_overlay. I attached a screenshot, artifacts.png, which is what I see on OSX Mavericks when the app first opens with the patch applied. Seems to replicate always. If I undo the patch and rebuild, the artifacts go away. This looks like it could be an uninitialized drawing buffer or some such. Needs deeper investigation. So for now, continuing to leave the "#ifdef APPLE" clause in redraw_overlay() until this is resolved.

#15	greg.ercolano 16:57 Apr 28, 2015

I played with this for several hours and could not figure out what actually causes the weird drawing artifacts in the screenshot. Was hoping that if I could, I could apply your patch to prevent redrawing both overlay and window. The problem seems specific to certain versions of OSX; not all my macs show the problem. For instance, your patch worked fine on 10.4.11, 10.6.8, and 10.10.1, but not 10.9.4. Not sure about others like (Lion and Mtn Lion)