FLTK logo

Re: [fltk.general] Fl_Image_Surface, alpha, caching fl_draw

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.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Fl_Image_Surface, alpha, caching fl_draw Bill Spitzak Jun 03, 2021  
 
If your image consists entirely of black text where it is transparent everywhere it is not black, then in fact the color channels would be black everywhere. What you are getting on the edges of your letters sounds like it is gray (with a partial alpha channel) and thus lighter than black, and this is why the letters look thinner.


On Wed, Jun 2, 2021 at 11:24 PM Evan Laforge <qdunkan@gmail.com> wrote:
Hi, I recently had the clever idea to accelerate drawing of text in my
app by caching the output of the fl_draw in an image.  I used
Fl_Image_Surface, and it almost works... except the output has no
alpha channel.  Since the text is always black, I made a copy of the
image and inferred an alpha with `0xff - avg(r, g, b)` but the results
are noticeably thinner than the native antialiased fl_draw output.
The black is still entirely opaque as it should be, but the
transparent parts are more transparent.

Is the alpha channel non-linear in some way?  Or is `1 - avg(r, g, b)`
too simplistic?

And of course, is there some better way than manually copying the
image and inferring an alpha channel?  When the OS drew the text in
the first place, surely it was using alpha... is there any way to get
my hands on that?  I notice it uses fl_read_image(), which does have
an alpha argument... but it's just a hardcoded value.  Tracking down
the OS X implementation, I wind up at a CGContextRef, and it looks
like these may or may not have alpha info.  In fact,
Fl_Cocoa_Screen_Driver.cxx looks like it does actually use a depth=4,
but fl_read_image is confusing.  It looks like if its alpha arg is
non-zero and read_win_rectangle returns an image with alpha, then it
leaves the alpha intact, but copies it into another Fl_RGB_Image, so
we can get the array out, so we can make it into another Fl_RGB_Image,
in Fl_Quartz_Image_Surface_Driver::image... which always passes
alpha=0.

Regardless of the alpha situation, wouldn't it be faster and simpler
for fl_read_image to directly return the Fl_RGB_Image from the
relevant screen driver, instead of making multiple copies and fiddling
with the alpha in complicated ways?  I assume this arose due to
history, but maybe we could have a direct path and leave fl_read_image
for backward compatibility.

Alternately, I'm sure caching text drawing is a common thing to do...
has anyone done something like this, and can share how they did it?

I'm using fltk-1.4 on OS X.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CACbaDy5H_yHhPur%3DZJUQhO-kM%2B6wzZJumBu_4vNzm%3Dnrb51oVA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAL-8oAj0c-m2BgC1tF4unv_sBk7quaXkPjK%2BDobaLfwxcB9STQ%40mail.gmail.com.
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'.