Support for OverlayWindow is missing?

[ericu]

trafficstars

OverlayWindow needs a way to supply an overlay-drawing function. I don't see a way to do that; it looks like it's not supported yet.

It would probably be more useful to have it [and Group] automatically delegate to an optional overlay-drawing function on each of its children, since likely you'll have widget-specific overlays, but that would be a departure from the base FLTK behavior. I haven't used it myself. Looking back at the old FLTK C++ code I'm replacing with Haskell, I see that I implemented my own overlay without using OverlayWindow, for a specific widget that needed overlay-like behavior. It's less efficient, but was fast enough. I think I'd intended to move it to the real overlay if it turned out to be necessary, and it never was.

I suspect this feature isn't high-priority, but I don't know how widely-used it is in FLTK.

[deech]

I personally never understood why Fl_Overlay_Window was useful over just overriding the draw of Fl_Double_Window. And there seem to be other ways of doing offscreen drawing for smoother graphics as well. Can you provide a small use case?

[ericu]

I believe the general idea is to allow for small, transient stuff to be drawn on top of a page that's expensive to render, so that you can e.g. draw a quick selection box without having to re-render everything underneath. Sometimes that drawing has to be more complex than flcOverlayRect can cover. These days hardware is so fast that I don't personally need that. I'm planning just to do 2 passes of regular drawing, since a full refresh is pretty cheap for me. But not everybody's using new hardware and a reasonably-cheap drawing function.

So I don't have a use case for you. Perhaps the best thing to do it just to document that OverlayWindow isn't supported, until such time as you have demand for it.