| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #1860
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | OpenGL |
|---|
| Summary: | Would like ability to specify software rendering for OpenGL contexts |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | d.zimmer |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | Will Not Fix |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | d.zimmer
19:14 Jan 18, 2008 |
| I'm not sure what the current policy on enhancements to 1.1.-current is, but anyhow, here goes (I had to sneak this in as a low priority fix, not unjustifiable since current behaviour has undesirable side-effects).
I've found it extremely useful to add the ability to dynamically switch to software rendering from within applications, to get around buggy OpenGL implementations. On win32 at least, this also allows me to ensure that I get a 32-bit depth buffer, instead of 16-bit hardware-accelerated, which does happen.
The current FLTK code will choose hardware over software on win32, and will always request a direct rendering context for Unix.
The following changes, allow me to specify that I will only accept indirect/software contexts. It has only been compiled and tested on win32, but I think the Unix code is ok.
Don.
/////////////////////////////////////////////////////////////////
enumerations.h // add FL_INDIRECT enumeration
enum Fl_Mode { // visual types and Fl_Gl_Window::mode() (values match Glut)
FL_INDIRECT = 1024 // Indirect rendering context, or generic implementation on win32
};
gl_start.cxx // modify unix call to fl_create_gl_context()
#else
context = fl_create_gl_context(fl_visual, gl_choice);
#endif
Fl_Gl_Choice.H // modify unix block for fl_create_gl_context()
#else
GLContext fl_create_gl_context(XVisualInfo* vis, const Fl_Gl_Choice* g);
static inline
GLContext fl_create_gl_context(Fl_Window*, const Fl_Gl_Choice* g) {
return fl_create_gl_context(g->vis, g);
}
#endif
Fl_Gl_Choice.cxx // modify win32 and unix blocks
if ((m & FL_INDIRECT) && !(pfd.dwFlags & PFD_GENERIC_FORMAT)) continue;
// see if better than the one we have already:
# else
GLContext fl_create_gl_context(XVisualInfo* vis, const Fl_Gl_Choice* g) {
GLContext shared_ctx = context_list ? context_list[0] : 0;
Bool direct = (g)? !(g->mode & FL_INDIRECT) : True;
GLContext context = glXCreateContext(fl_display, vis, shared_ctx, direct);
if (context)
add_context(context);
return context;
}
# endif
Fl_Gl_Overlay.cxx // modify unix call to fl_create_gl_context()
context(fl_create_gl_context(fl_overlay_visual, g), 1);
///////////////////////////////////////////////////////////////// | |
| |
| #2 | matt
13:31 Jan 21, 2008 |
| Sorry, no new features. I bumped this to 1.2 | |
| |
| #3 | matt
01:36 Jan 20, 2023 |
| AS we have reached the year 2023, OpenGL is probably one of the most mature libraries out of all libraries. It's so mature, that it is already being phased out again and replaced by Metal and others.
I see absolutely no advantage in overriding the OpenGL driver choice, so I will close this as "Will Not Fix". | |
[ Return to Bugs & Features ]
|
| |
