[ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]
|Status:||4 - Pending|
|Priority:||3 - Moderate, e.g. unable to compile the software|
|Scope:||2 - Specific to an operating system|
|Summary:||Mac OS X Fl_Gl_Window bugs - all FLTK versions|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
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.
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.
10:27 Apr 05, 2013
|I have added files for two test programs that demonstrate the reported Gl_Window bugs. ||
21:26 Apr 05, 2013
|Assigning this STR to myself. |
showing the problem/solution, and agree with the suggested fix
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.
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.
12:01 Apr 07, 2013
|Oops; named those attachments wrong: |
..those should have been called 'nested-window' instead of 'rasterpos',
as they are regarding the nested issue.
12:17 Apr 07, 2013
|Regarding #2: |
Confirmed problem with gl_draw()/glRasterPos() issue.
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.
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..
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.
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:
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?
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).
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.
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.
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)
[ Return to Bugs & Features | Post Text | Post File ]