Opengl acceleration in 1.3.4. on windows...

[Roman K]

I've got issues with OpenGL acceleration: On some windows machines Fl_Gl_Window does very slow rendering, presumably only by software emulation.
When compiling/linking to previous version of fltk, everything works just fine - with hardware acceleration.
Note that it happens only on some machines, however I don't thing windows is at fault here because with previous FLTK everything is fine.

Doing more research:

    Fl_Gl_Choice::find(FL_RGB | FL_STENCIL | FL_DEPTH, 0);

retuns just fine, however pfd.dwFlags returns hexadecimal 0x8465, which means:

PFD_SWAP_LAYER_BUFFERS is set
PFD_SWAP_COPY is set
PFD_SUPPORT_OPENGL is set
PFD_DRAW_TO_WINDOW is set
PFD_OVERLAY_PLANE is set
PFD_GENERIC_FORMAT is set !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


For old fltk (for which acceleration is working), pfd.dwFlags give value 0x8425, that means for this PFD_GENERIC_FORMAT is NOT set (the only difference).

The windows documentation state: if PFD_GENERIC_FORMAT is set, "The pixel format is supported by the GDI software implementation, which is also known as the generic implementation. If this bit is clear, the pixel format is supported by a device driver or hardware".

As those two differ by fltk version, I presume this happened somewhere during  "Opengl device driver abstraction".

Any ideas?

R.

[Ian MacArthur]

Hi Roman,

Well, that’s interesting; I have a laptop with Win10, and some of my GL code is inexplicably slow on it, using fltk-1.4.x. I just assumed it was a duff old laptop and Win10...

But this does seem like there might be something we have changed, albeit inadvertently, with the way we are enumerating GL capabilities.

[Albrecht Schlosser]

I think STR #3119 is related but not a direct reason or solution:
http://www.fltk.org/str.php?L3119

I tried to fix the issue described in STR #3119 and posted a patch but
didn't commit it yet:
http://www.fltk.org/strfiles/3119/support_composition_v2.diff

The patch has several printf's that may be helpful. Since I didn't
really know what I was doing (TM) ;-) and didn't have different test
systems I suggest that Roman and/or you (Ian) should try the patch and
see if you can fix both issues together. Both of you seem to know GL
issues much better than me.

Note: IIRC the algorithm tries to find the "best" (whatever that is)
pixel format but it is heavily dependent on the order the pixel formats
are enumerated in the system's pixel format list by

DescribePixelFormat(gc, i, ...)

where i is the index in the system's (AFAICT).

I'd very much appreciate if you could (a) verify/confirm the patch and
(b) resolve the issue of this thread. TIA

[Albrecht Schlosser]

On 12.04.2017 20:50 Ian MacArthur wrote:

> On Wed Apr 12 2017 17:44:57, Roman K wrote:
>> I've got issues with OpenGL acceleration: On some windows machines Fl_Gl_Window does very slow rendering, presumably only by software emulation.
>> When compiling/linking to previous version of fltk, everything works just fine - with hardware acceleration.

Please clarify:
(a) are you really observing slow behavior in 1.3.4, or did you mean
1.4.0 ?
(b) which "previous version" of fltk works "just fine" ?

I'm asking because Ian wrote:

> Well, that’s interesting; I have a laptop with Win10, and some of my GL code is inexplicably slow on it, using fltk-1.4.x. I just assumed it was a duff old laptop and Win10...

So Ian was likely talking about differences between 1.3.4 (1.3.x?) and
1.4.0 whereas you (Roman) wrote that you observed slow behavior in
1.3.4. I'm confused...

BTW: what Windows version do you use? Is there a difference between
Windows versions as well? See STR #3119...

Okay, trying to help a little more... see attached files:

I stripped down the relevant parts of FLTK 1.3.4 (gl_1.3.4) and FLTK
1.4.0 (gl_1.4.0) by removing conditional statements (#if...). The result
looks mostly identical but there are some differences.

Particularly I believe that it _may_ be possible that chosen_pfd is left
uninitialized in both versions if none of the pfd's "satisfy our
requirements", i.e. one of the 'continue' statements is reached for all
pfd's (maybe not very likely, but possible). In this case

g->pfd = chosen_pfd;

would assign an undefined value.

In gl_1.3.4.cxx I don't see any assignment to g->pfd at all in the code
at lines #45-49.

Now I'm even more confused.

[Manolo]

Could you, please, report what version of FLTK creates this issue?
Your message mentions 1.3.4, but "Opengl device driver abstraction" is only ìn 1.4.0

Could you also report what is the value of this other flag: PFD_GENERIC_ACCELERATED

My reading of the documentation is that the pixel format is supported by the generic
implementation only when  PFD_GENERIC_FORMAT is ON and PFD_GENERIC_ACCELERATED is OFF.
What I get here (with VirtualBox as hardware) is that both flags are ON.
In such situation, I don't think the hardware acceleration would be unused.