FLTK logo

Re: [fltk.coredev] Re: [master] 9df287b - Cleaner access to Fl_Gl_Window_Driver objects.

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: [master] 9df287b - Cleaner access to Fl_Gl_Window_Driver objects. Albrecht Schlosser Apr 30, 2021  
 
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.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.