[AD] [ alleg-Bugs-3116161 ] Offscreen font rendering looks wrong

["SourceForge.net" <noreply@xxxxxxxxxx>]

Bugs item #3116161, was opened at 2010-11-22 20:24
Message generated for change (Comment added) made by trentg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3116161&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Addons
Group: 4.9
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: SiegeLord (siegelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Offscreen font rendering looks wrong

Initial Comment:
Observed on Linux with 5.0rc1. Text rendered on an offscreen bitmap looks noticeably "thinner". Here's test case. The offscreen text is the top line. Needs the DejaVuSans.ttf font from examples:

#include <allegro5/allegro.h>
#include <allegro5/allegro_font.h>
#include <allegro5/allegro_ttf.h>

int main(int argc, char* argv[]){
  
    al_init();
    al_init_font_addon();
    al_init_ttf_addon();
    ALLEGRO_DISPLAY* disp = al_create_display(800, 600);
    al_clear_to_color(al_map_rgb_f(0, 0, 0));
    
    ALLEGRO_FONT* f = al_load_font("DejaVuSans.ttf", 16, 0);

    ALLEGRO_BITMAP* bmp = al_create_bitmap(400, 200);

    al_set_target_bitmap(bmp);
    al_clear_to_color(al_map_rgb_f(0, 0, 0));
    al_draw_text(f, al_map_rgb_f(1,1,1), 0, 0, 0, "Test abcdefg.");
    
    al_set_target_bitmap(al_get_backbuffer(disp));
    al_draw_bitmap(bmp, 0, 0, 0);
    al_draw_text(f, al_map_rgb_f(1,1,1), 0, 28, 0, "Test abcdefg.");

    al_flip_display();
    al_rest(10.0);
}

----------------------------------------------------------------------

>Comment By: Trent Gamblin (trentg)
Date: 2010-11-24 15:04

Message:
I also think we should use premultiplied alpha as the default. Rather then
setting the blender twice like in the "solution" below, all you have to do
is load the font glyphs with premultiplied alpha (I have a very simple ~10
line patch for this) and set the blender to (ADD, ONE, INVERSE).

----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2010-11-24 14:59

Message:
Ok, we just figured this out in #allegro. Basically, the alpha blending is
applied twice, once when (A) drawing to the offscreen then when (B) drawing
to screen. Assume a pixel has color 1,1,1,0.5. The offscreen is initialized
to 0,0,0,0:

With ALPHA/INVERSE blender:
A: RGBA =
1*0.5+0*(1-0.5),1*0.5+0*(1-0.5),1*0.5+0*(1-0.5),0.5*0.5+0*(1-0.5) =
0.5,0.5,0.5,0.25
B: RGB =
0.5*0.25+0*(1-0.25),0.5*0.25+0*(1-0.25),0.5*0.25+0*(1-0.25)=0.15,0.15,0.15

So it gets way too dark. The solution is to use additive blending either
for A or for B:
ONE/ONE blender:
A: RGBA = 1,1,1,0.5
ALPHA/INVERSE blender:
B: RGB = 0.5,0.5,0.5

Which is what we would expect. This is another shortcoming of us not using
pre-multiplied alpha. If we were using premultiplied alpha, then the blend
mode would be ONE/INVERSE. And the same white pixel would be premultiplied
to 0.5,0.5,0.5,0.5. Now the drawing would look like:

A: RGBA=0.5+0,0.5+0,0.5+0,0.5+0=0.5,0.5,0.5,0.5
B: RGB=0.5,0.5,0.5

Additionally, if the offscreen bitmap is not all 0, we likely want to
handle the alpha separately, i.e. use additive for the alpha channel, no
matter if the color components are premultiplied or not.

Leaving this open for now as I more and more think not using premultiplied
alpha by default is a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3116161&group_id=5665