On 4/30/21 10:02 AM Manolo wrote:
> @Albrecht:
> OK. I had misunderstood your initial proposal. It's not about
> reconsidering all trees of classes.

Certainly not!

> 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 ?

Yes, more or less, we can reduce it to that. Sorry for the confusion, my
"request" was really unclear. It was a quick shot when I saw the commit.

> 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.

I strongly believe that this should be a public method of Fl_Window and
derived classes. Based on what you and the docs say (thanks for that!) a
very simple functional solution would be:

(pbulic) Fl_RGB_Image * Fl_Window::capture(x, y, w, h) const {
   return fl_capture_window_part(this, x, w, w, h);
}

However, I'd rather like it technically refactored as a normal Fl_Window
method.

> 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.

Yes, I agree this is a good reason to implement the new method.

> 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

Yes, I see...

> Thinking about that, we could link to a new
> Fl_Window::capture_rectangle() member function just as well.

A missing piece of Fl_Window::capture_rectangle(), compared to
fl_read_image() would be that fl_read_image() can create an alpha
channel in case the user wants one. IIRC this would be a constant for
all pixels.

In the docs of fl_capture_window_part() you write: "The image depth may
differ between platforms". What exactly does this mean? Are there
platforms (macOS?) where you can "capture transparency" from an existing
window? Or what else does it mean?

If this (alpha channel on certain platforms) does not preclude it, we
could also add an optional 5th parameter 'alpha' to return an image with
a preset alpha channel. Maybe. I don't know the details, this should be
discussed further.

Regarding the implementation as Fl_Window method or a function: I think
normal methods are more natural and easier to find. I've never been a
friend of such functions like fl_read_image(), they're hard to find in
the docs and not intuitive.

Regarding the naming convention: I believe that '_window' and '_part'
are obsolete if we define an Fl_Window method, hence my short proposal
(now with optional alpha):

   Fl_Window::capture( x, y, w, h [, alpha] );

If we add this we can /deprecate/ fl_read_image() and point the user at
the new method.

What do you think?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/9b62055d-45d7-cb91-05a1-50f06d1f1bd8%40online.de.