Andreas Raab wrote:
> Hans-Martin Mosner wrote:
>> Looks like some of the changes in trunk broke the mechanisms by which 
>> the project view displays the project name:
>>
>> I have not yet found the culprit, my suspicion is that this could be 
>> a side effect of antialiased font rendering.
>> The core of the problem is somewhere in the drawing of a string morph 
>> on a fresh canvas.
>> When you execute "(StringMorph contents: 'X') imageForm bits asArray" 
>> you will get different results in the current trunk image and in a 
>> 3.10.2 image, for example. I have not yet tried it in other images.
>
> Correct. I tried to dig in a little and the issue seems to be a result 
> of the 16->32 bpp expansion of the anti-aliased font glyphs. An easy 
> test case is this:
>
> self assert: ((StringMorph new contents: ' ') imageFormDepth: 32) bits 
> first = 0.
>
> It would be interesting to see if this is an artifact of just the 
> expansion (in the StrikeFont's glyphs) or if there is more than that. 
> If anyone has a 32bpp version of one of the fonts I'd like to try.
>
> Cheers,
>   - Andreas
Hi Folks,

The fix is in the trunk. There are several issues here.
1) StringMorphs can not be cached by the hand anymore. This has no 
relation with the problem you fond, but I found it while testing. So I 
added StringMorph >> hasTranslucentColor
2) ProjectViewMorph used #stencil:at:color: to draw the project name. 
Changed it to #drawImage:at:
3) We have a bug in BitBlt. When using #rgbAdd, alpha values are not 
actually added. What happens is more like (alpha1+alpha2)>0 ifTrue: [ 
1.0] ifFalse: [0.0]. The strange thing is that the code seems to be 
right, and it works ok in the simulator. Just sent an email to VM-Dev 
asking for help on this. As a workaround, I defined 
StringMorph>>imageForm:forRectangle: to use a white background instead 
of a transparent one.

Cheers,
Juan Vuletich