Hi folks,

Unfortunately, the problem is not in the fonts code. There is a bug in 
Bitblt, rule 28. Rule 28 is supposed to take the minimum value between 
source and destination. I use it to render 32 bit per pixel fonts. 
Unfortunately there is a bug in BitBlt. The result values for r, g and b 
are computed correctly. But the alpha channel is always set at zero 
(i.e. transparent). Usually the VM / OS ignores the alpha channel of the 
display. But with composite window managers on Linux, it is honored, and 
the bug is exposed.

You can try for yourself. Evaluate:

(Display pixelValueAt: 10 at 10)printStringBase: 16

You'll get something like this '16rFF455286'. The FF at the first byte 
is alpha. FF means opaque. Now, run the following code, and with the 
mouse go and paint the top left area of your display. Then do click. Do 
not clean the garbage on the screen yet.

    f := Form extent: 20 @ 20 depth: 32.
    f fillWithColor: Color red.
    aBitBlt := BitBlt
        destForm: Display
        sourceForm: f
        fillColor: nil
        combinationRule: 28
        destOrigin: Sensor cursorPoint
        sourceOrigin: 0 @ 0
        extent: f extent
        clipRect: Display computeBoundingBox.
    [Sensor anyButtonPressed] whileFalse:
        [aBitBlt destOrigin: Sensor cursorPoint - (10 at 10).
        aBitBlt copyBits].

Now check (f pixelValueAt: 10 at 10) printStringBase: 16. You'll see that 
inside form f, the alpha is FF, i.e. opaque again.

Now print (Display pixelValueAt: 10 at 10) printStringBase: 16. I get 
'16r450000'. Adding the missing leading zeros, it is '16r00450000'. You 
can see that Bitblt correctly left the red unchanged and made zero green 
and blue. Unfortunately, alpha went to zero.

I believe this is a bug. Rule 28 means "take the minimum between source 
and destination". It could do the same for alpha, or it could leave 
alpha unchanged. Both would be acceptable behaviors. But setting alpha 
to zero for no good reason is a bug.

Perhaps there is some bitblt rule that can be used for setting alpha to 
255 after rendering text. If someone knows how to do it, it could be a 
good workaround.

Another workaround is to do
    Prederences setPreferencesFrom: #((subPixelRenderFonts false))
This will turn off subpixel rendering, using only gray levels for AA. 
This uses BitBlt rule 34, that does not have this problem.

Cheers,
Juan Vuletich

Mariano Martinez Peck wrote:
>
>
>     WRT composite window managers on Linux, it seems I need to make
>     sure the alpha channel is set to 1.0. I'll do it. I'll need help
>     with testing it, though.
>
>
> Just let me know when and how and I will test it as soon as I have 
> time. I was one of those who has that problem.
>
> cheers,
>
> mariano
>
> pd: juan: si me pedis algo, pedimelo en castellano jajaj ;)
>
> ------------------------------------------------------------------------
>
>
>   
> ------------------------------------------------------------------------
>
> Internal Virus Database is out-of-date.
> Checked by AVG. 
> Version: 7.5.524 / Virus Database: 270.6.6 - Release Date: 8/19/2008 12:00 AM
>