| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3168
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | MacOS |
|---|
| Summary: | remove dependency to deprecated AGL library |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | manolo |
|---|
| Assigned To: | manolo |
|---|
| Fix Version: | 1.3-current (SVN: v10498) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | manolo
00:43 Dec 14, 2014 |
| It is desirable to remove the dependency of FLTK's mac platform
to the deprecated AGL library, and replace it by standard
cocoa system calls.
This is what does the attached cocoaGL.patch
The patch requires no change to application code.
The patch also allows Fl_Gl_Window's to be drawn at high resolution
when mapped to a 'retina' display. But this needs some support
by the calling application:
- call
Fl::use_high_res_GL(1);
at application start
- adapt calls to glViewport() in draw functions:
glViewport(0, 0, pixel_w(), pixel_h());
using two new member functions Fl_Gl_Window::pixel_w() and pixel_h
that return the window size in pixel units.
These functions are synonyms of Fl_Widget::w() and h() on non
mac platforms.
I have tested all GL-based demo programs of the test directory,
and all those in Erco's FLTK cheat page.
The large gmsh application is also reported to work well with the
new code.
I have detected a (minor) problem in the "3D sphere with light"
test of the cheat page:
light is lost when switching resolution (either way).
I'm unable to repair this problem that involves OpenGL concepts
I don't understand.
Help needed. | |
| |
| #2 | manolo
09:35 Dec 14, 2014 |
| A fix for the problem mentionned above when changing resolution:
Put
#if defined(__APPLE__) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7
// detect if the window was moved between low and high resolution displays
if (Fl_X::i(this)->retina.changed_resolution){
Fl_X::i(this)->retina.changed_resolution = false;
invalidate();
gl_context_update(context_);
}
#endif
at the very beginning of function Fl_Gl_Window::make_current()
in file src/Fl_Gl_Window.cxx | |
| |
| #3 | greg.ercolano
09:41 Dec 14, 2014 |
| @manolo: great work.
Regarding the resolution change; you clarified it's not
a window resize or changing the current display's resolution,
but instead "moving the window between two displays of distinct
resolution".
That's interesting because I suppose that could mean moving the
window between two separate graphics cards, and since opengl
initialization probably ties into the graphics hardware, that
could be a difficult issue in the opengl drivers to try to
migrate the opengl state from one graphics card to another.
Anyway, it's /probably/ not a concern of yours, it might either
be the opengl drivers or the app code should maybe do some kind
of extra work to reinitialize the lighting model in maybe the
resize() code. | |
| |
| #4 | greg.ercolano
09:41 Dec 14, 2014 |
| Oh, OK, our messages passed in time.. sounds good if that fixes it. | |
| |
| #5 | manolo
14:16 Dec 14, 2014 |
| To simulate (as I do) high resolution graphics without a retina display,
use the Quartz Debug application as explained in:
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Testing/Testing.html
in "To enable high-resolution display modes"
Quartz Debug itself is part of the "Graphics tools for Xcode"
available from Apple's developer web site. | |
| |
| #6 | manolo
05:33 Dec 15, 2014 |
| With attached cocoaGL2.patch, all detected problems are fixed. | |
| |
| #7 | fabien
12:35 Jan 05, 2015 |
| Patch Looks good Manolo, great works.
Could it be possible to not use a literal value for the scale factor and use a generic API (like the NSWindow HIWindowGetBackingScaleFactor?), so not assuming that the scale factor is (currently only) 2 ? | |
| |
| #8 | fabien
13:12 Jan 05, 2015 |
| Actually, I think we could use [UIScreen scale] that automatically gives 1 for standard displays and 2 for retina display (as for today), with no need to assume its current value.
See:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIScreen_Class/index.html#//apple_ref/occ/instp/UIScreen/scale | |
| |
| #9 | manolo
02:34 Jan 06, 2015 |
| [UIScreen scale if for IOS only.
[NSScreen backingScaleFactor] would be the corresponding MacOS
call, but it's not recommended according to the Apple doc,
that suggests using [NSView convertRectToBacking:] instead.
We have this function
int Fl_X::resolution_scaling_factor(Fl_Window*)
that now returns either 1 or 2, but can be modified
to return other values if it becomes useful.
So, I believe we have a good API that can handle hypothetical
higher future resolutions. | |
| |
| #10 | manolo
03:32 Jan 06, 2015 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
