STR #3252

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 | Prev | Next ]

STR #3252

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:2 - Specific to an operating system
Subsystem:MacOS
Summary:Fl_Native_File_Chooser and Fl_Gl_Window on MacOS X
Version:1.3-current
Created By:geuzaine.acm.caltech
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 geuzaine.acm.caltech
05:15 Aug 20, 2015
test_native.cxx
2k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 geuzaine.acm.caltech
05:15 Aug 20, 2015
There seems to be a little bug in the way Fl_Native_File_Chooser and Fl_Gl_Window interact on MacOS X in the special case when the MacOS X file chooser is in "gallery" mode, i.e., when the icons are displayed graphically in a scrollable horizontal panorama.

To reproduce the problem:

1) Compile the attached file with "fltk-config --use-gl --compile test_native.cxx" on MacOS X, and run it. A green OpenGL window should appear.

2) Click and move the mouse in the green window: the square should move to the
right.

3) Press "Ctrl+o" and choose the "gallery" mode to view the file icons in a scrollable horizontal gallery.

4) Close the file chooser by clicking on "Cancel".

5) Click in the green window and move the mouse again: the square does not move. This problem does not appear for all other file viewing modes.
 
 
#2 greg.ercolano
05:06 Jul 22, 2016
Just adding my two cents..

Verified on OSX 10.7.5.

Seems like gallery mode of OSX's browser messes up the opengl context somehow,
likely because it uses opengl internally.

I found if I added win->resizable(win); just before the show(),
really bad stuff happens when I resize the window after the browser is shown/cancelled.
The window simply doesn't redraw properly from then on.

Seems like our opengl state gets ruined by the browser's internals.

Needs some investigation..
 
 
#3 greg.ercolano
20:44 Jul 22, 2016
OK, seems there's a lot about this on the net.

Internally Fl_Native_File_Chooser (or "FNFC") uses the OSX function
NSOpenPanel to open the native dialog.

Googling for "NSOpenPanel OpenGL" seems to yield a lot of hits about
this same issue where the file chooser wrecks opengl apps.

I've tried poking at this quite a bit and can't figure out how to
get opengl working again after the dialog is closed; I've tried various things
after the native.show() method returns:

   a) win->invalidate() -- to force glOrtho() et al
   b) hide() + show()ing the window (being sure it unmaps)
   c) resetting the gl context, with e.g. win->context(0,1); win->make_current()

I'm not really sure what the Apple file browser is breaking here..
it seems to be the opengl context, but I'm pretty sure that's getting
recreated by (b) or (c) above. (See docs for Fl_Gl_Window::context() re: (c))

Maybe Manolo might know what this is; seems like some internal OSX / OpenGL thing,
possibly along the lines of what's shown here:

    Restore OpenGL context after showing file dialog
    ------------------------------------------------
    https://github.com/waneck/systools/pull/30/files?diff=split

..which describes how to save and restore the current opengl context from .mm files (ObjectiveC).
 
bottom left image   bottom right image

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

 
 

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