@Albrecht:

OK. I had misunderstood your initial proposal. It's not about reconsidering all

trees of classes. It's just about adding to the public API a function to capture

a rectangle in a window, whatever the nature of that window, and to return an

Fl_RGB_Image object. Is that correct ?

That function already exists, it's fl_capture_window_part()

     see https://fltk.gitlab.io/fltk/group__fl__drawings.html#ga74c16eb73f1a1be989a16da9086622f0

The returned Fl_RGB_Image is scaled (with Fl_Image::scale()) so that its drawing size

is the size of the rectangle asked for, and its data size is the number of pixels present

in the captured rectangle which varies with the display's scaling factor.

Thus, it's not a public member of class Fl_Window as you proposed, but it's functionally identical.
We have the possibility to change that since 1.4 is not out yet. Let me know what you believe is best.

However,  I have put this feature in the form of a function rather than a member of class

Fl_Window, I believe, because it is the correct extension of the classic fl_read_image() function

for the situation arising with FLTK 1.4 and HighDPI displays :  behind rectangle

X,Y,W,H in FLTK units there are many more than WxH pixels, and the returned

uchar array of function fl_read_image() is not able to convey that information.

The doc of fl_read_image() proposes a link to the new fl_capture_window_part() :

   https://fltk.gitlab.io/fltk/group__fl__drawings.html#ga0cdc05d3f7689e1c6b8a26fd0bd97233

Thinking about that, we could link to a new Fl_Window::capture_rectangle() member function

just as well.