FLTK logo

STR #2944

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

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 ]
Name/Time/Date Filename/Size  
 
#1 lhquam
10:19 Apr 04, 2013
fltk-1.3-patches-20130404.txt
3k
 
 
#2 lhquam
10:26 Apr 05, 2013
GlWindow-rasterpos-bug.c++
5k
 
 
#3 lhquam
10:26 Apr 05, 2013
GlWindow-nested-window-bug.c++
4k
 
 
#4 greg.ercolano
21:26 Apr 05, 2013
rasterpos-fix-before-and-after-screenshot.jpg
26k
 
 
#5 greg.ercolano
23:51 Apr 05, 2013
rasterpos_bugfix.patch
2k
 
 
#6 greg.ercolano
12:17 Apr 07, 2013
gl_draw--before-and-after-screenshot.jpg
78k
 
 
#7 greg.ercolano
15:31 Apr 28, 2015
artifacts.png
20k
 
     

Trouble Report Comments:

Post Text ]
Name/Time/Date 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)
 
     

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.