Andreas Raab wrote:
> Juan Vuletich wrote:
>> You're right. It seems we need the second BitBlt pass even for black 
>> text. Just added that to the trunk. I also added a preference, 
>> #properAlphaForBlackText that defaults to true, but can be set to 
>> false if performance is more important that correctness.
>
> Yeah, good choice. It turns out that there is a measurable performance 
> difference between single-pass and two-pass rendering (for example in 
> the browser benchmark). Is it possible to merge these specific two 
> rules into a single-pass rendering to retain the original single-pass 
> performance?

Well, each uses a different colorMap, so it is a bit tricky. On the 
other hand, for black text, the second pass really should not be 
necessary. When we get this right (more below), then the price for the 
second pass is only paid for colored text.

The second pass is currently needed because of a bug in BitBlt. The 
following code
f1 := Form extent: 8 at 8 depth: 32.
   f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.7).
   f2 := Form extent: 8 at 8 depth: 32.
   f2 fillColor: (Color r: 0.5 g: 1.0 b: 0.7 alpha: 0.9).
   bb :=(BitBlt toForm: f1) sourceForm: f2; combinationRule: 37; copyBits.
   (f1 colorAt: 2 at 2)
should evaluate to  (TranslucentColor r: 0.501 g: 1.0 b: 0.494 alpha: 
0.627), but answers Color transparent. The problem is in 
#partitionedMul:with:nBits:nPartitions: as it ignores the last argument. 
Will send a mail to VM-dev about this.

Cheers,
Juan Vuletich

>> Note #1. This needs a rather recent VM, that includes my fixes to 
>> BitBlt done in April. Your latest Windows VM is ok.
>>
>> Note #2. If the trend is to fix the handling of alpha channel in the 
>> image, at some point the fix to ignore Display alpha must be removed 
>> from the Linux VM, to play well with composing window managers.
>
> Yes, we should. It would be nice if we could actually control the 
> alpha correctly.
>
>> Note #3. The second pass stuff is done in GrafPort, but not in 
>> BitBlt. Do you think it is better to move it up to BitBlt?
>
> BitBlt, since it's used directly from StrikeFont and not via Canvas.
>
> Cheers,
>   - Andreas
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.392 / Virus Database: 270.13.44/2282 - Release Date: 08/04/09 18:01:00
>
>