FreeLists / haiku-appserver / [haiku-appserver] Re: BView::ClipToPicture

[Adi Oanca <adioanca@xxxxxxxxxxxxxx>]

DarkWyrm wrote:
>>      IMHO, the best solution is to use a 1bit surface, and draw with a 
>>single color (changing the color 
>>would not be possible) and disable AA for text rendering.
> 
> Perhaps the 32-bit thing is too expensive. The only reason that I was 
> considering it was because of AA. I'm still not convinced that going 
> without AA is such a great idea. Attached to this e-mail (assuming that 
> it isn't filtered out) is a comparison I did. At small point sizes, AA 
> makes all the difference in the shape of some characters. I tend to be 
> very picky about details on a lot of things, fonts being one of them, 
> so I ask you is this something that you gentlemen are willing to live 
> with? If you guys are ok with this, I'll live with it. :)

        I don't think we have a choice.
        I think you are missing my point. I fully agree, fonts without AA is 
something that I definitely 
don't want to see. But we're dealing with a [clipping] region here. The region 
works with 2 values 
only - a point is in the region or it isn't. The non-AA text that you see(on 
the right), in fact is 
not a text at all - the points that compose it are just... usual points, just 
like you put pixel by 
pixel. For app_server to have what you want, we need to add transparency 
support for clipping 
operations - and you know, that we won't have until at least R2.

        [Basic transparency support we will have, I know. But it is not used in 
clipping operations but in 
displaying views in a window. How is that done: by drawing from back to front.]



Bye,
Adi.