Fix issue #254: remove hardware overlay support (X11)

23 views
Skip to first unread message

Manolo

unread,
Nov 25, 2021, 11:26:40 AM11/25/21
to fltk.coredev
I propose the series of modifications given in the attached patch
to fix for 1.4 issue #254: remove hardware overlay support.
This would remove one milestone item for Release 1.4

The proposal leaves unchanged the support of HAVE_GL_OVERLAY
for the WIN32 platform.
Can someone give info about whether this is functional?
With Windows inside VirtualBox, there's no access to such feature.

Any comment?
no-overlay.patch.txt

Bill Spitzak

unread,
Nov 25, 2021, 5:30:17 PM11/25/21
to fltkc...@googlegroups.com
I'm pretty certain it can be removed from Windows as well. The overlay is obsolete hardware, though it did exist on the Irix-NT machines we were using, and any kind of emulation is not any better than fltk doing it itself.


--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/a63ddeb6-59d3-4496-a090-f79720b4b451n%40googlegroups.com.

imacarthur

unread,
Nov 26, 2021, 3:59:35 AM11/26/21
to fltk.coredev
(As regards the WIN32 support for HAVE_GL_OVERLAY )

Only that I defer to Bill's greater wisdom!

FWIW, I can't recall ever seeing the HAVE_GL_OVERLAY set - in my Windows builds it is always set (by configure or cmake) to HAVE_OVERLAY, and HAVE_OVERLAY in turn is always 0 on any WIN32 builds I have ever looked at...
So unless there are folks who are *manually* setting HAVE_GL_OVERLAY in their config.h (which is possible but seems unlikely) then I can't imagine anyone has used this...

 

Manolo

unread,
Nov 26, 2021, 6:23:03 AM11/26/21
to fltk.coredev
Le vendredi 26 novembre 2021 à 09:59:35 UTC+1, imacarthur a écrit :

FWIW, I can't recall ever seeing the HAVE_GL_OVERLAY set - in my Windows builds it is always set (by configure or cmake) to HAVE_OVERLAY, and HAVE_OVERLAY in turn is always 0 on any WIN32 builds I have ever looked at...
So unless there are folks who are *manually* setting HAVE_GL_OVERLAY in their config.h (which is possible but seems unlikely) then I can't imagine anyone has used this...

OK. Then I attach a bigger patch that also removes  HAVE_GL_OVERLAY for the Windows platform.

Whereas the demo program test/gl_overlay runs nicely under macOS, it's incredibly slow with Windows inside VirtualBox
and it's wrong under the X11 platform (both inside VirtualBox or with XQuartz): the overlay is not cleared before being rewritten.
What do you see on plain Windows and Linux boxes with test/gl_overlay ?
Would it be useful to rewrite the GL overlay support following what's done in the macOS platform?
I've done that for the Wayland platform, and it runs just as on macOS.

no-overlay.patchV2.txt

Albrecht Schlosser

unread,
Nov 26, 2021, 7:11:45 AM11/26/21
to fltkc...@googlegroups.com
On 11/25/21 5:26 PM Manolo wrote:
> I propose the series of modifications given in the attached patch
> to fix for 1.4 issue #254: remove hardware overlay support.
> This would remove one milestone item for Release 1.4

+1

> The proposal leaves unchanged the support of HAVE_GL_OVERLAY
> for the WIN32 platform.
> Can someone give info about whether this is functional?
> With Windows inside VirtualBox, there's no access to such feature.

I have no idea, but see Ian's post.

> Any comment?

I propose to proceed with the X11 overlay stuff independent of the
Windows HAVE_GL_OVERLAY question so we can close issue #254.

The Windows stuff should be separated anyway in another issue / patch / PR.

One minor nitpick regarding the patch: the alignment in line 635 of the
patch might need adjustment (not tested):

Line # ca. 233 of new src/drivers/Xlib/Fl_Xlib_Graphics_Driver_color.cxx:

-      numcolors = fl_visual->colormap_size;
+    numcolors = fl_visual->colormap_size;

(or similar, edited manually)

Other than that: great, please go ahead. Thanks.

Reply all
Reply to author
Forward
0 new messages