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 May 01, 2021  
 
On 5/1/21 9:30 AM Manolo wrote:

On Friday, April 30, 2021 at 9:35:36 PM UTC+2 Albrecht Schlosser wrote:

    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?

GL windows return depth-3 images on all platforms.
Other windows return depth-4 on macOS and depth-3 on X11 and Windows.
Because the capture can mix GL and non-GL windows, depth conversions
are performed by the function when necessary.

Okay, thanks for the explanation.

I kept the depth-4 on macOS because this preserves the rounded angles of the window when the image is drawn: off-window pixels are fully transparent.
    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.

What is the use of a constant transparency value across all pixels of an image?

I don't know. I can imagine that you want to get an image for blending or for later manipulating of the alpha channel. I think it's just convenient to "say": please give me an image with a preset alpha channel.

If there's one, it's certainly possible to apply it when drawing that image.

My point /was/ backwards compatibility. If we wanted to deprecate fl_read_image() and tell users to use the new Fl_Window::capture() method instead, then this method needed to provide the same "features".

OTOH, thinking... If it's just different, then so may it be. We can't remove the old method anyway and the output format is different ... Yes, please forget compatibility, let's just add this new method as an alternative to fl_read_image() with a different output format (Fl_RGB_Image*).

--
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/7d6a1138-6062-1073-81db-aedf0542b381%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'.