Re: Antialiased fonts patch.

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]

Evgeny Kolesnikov wrote:
> Hi,
>
>   
>> At first I was completely against antialiasing support because of
>> performance impact. But it being optional decreases the later. However
>> there is one problem: your patch relies on text_layer to be RGBA8888
>> which was a mistake. RGBA8888 for text layer is vastly inefficient
>> especially on 16-bit framebuffer and CPUs with small cache. I had plans
>> to switch it to indexed color. Do you really need 8bits and 4 aren't
>> enough? 
>>     
>
> I use 8-bit in order to give GRUB ability to look and feel exactly
> as other parts of OS, so yes, 8 bits are required. If one can't allow
> this for his system - he can use 1-bit fonts. I don't really care about
> such situation just because other parts of desktop on such a system will
> be awful too.
>   
You forget that other parts of the system have access to video
acceleration capabilities, grub doesn't.
>   
>> If 4 are enough we could make text_layer IA44 (indexed-4 bits,
>> alpha 4 bits) if you need 8 bits we can do IA88. I'm not sure which one
>> is faster: firs one is more cache-efficient, second one requires less
>> ALU. Are you interested in implementing this?
>>     
>
> Actually I'm planning to add 32-bit AA (heh-heh). Sub-pixel AA for LCD
> monitors for complete match with xorg capabilities. And this just can't
> be done in indexed mode.
>
> So I can suggest to make division: 1-bit & indexed text layer vs
> 8(32)-bit & RGBA layer. First is for speed, second (and third) 
> is for beauty 
Splitting speed/niceness is ok as long as they share most of the code
and "speed" is default.
Perhaps we can have a variable:
set i_want_to_waste_time_in_booter=yes
But before we can go to such length for beauty we would need native
drivers first. No matter how you antialias if VBE accepts only 1024x768
which is stretched to 1280x800, it won't have any effect. Hence you need
to port native drivers to grub.
> (BURG project is already interested in - Bean, help
> me :)). 
He is of no authority here. If something is considered harmful it will
be rejected no matter what burg does.
> Doing it half-way will be nor fast nor appealing.
>
> And yes, I'm interested in doing it in most effective way: blitter,
> optimizations etc., just give me the direction.
>   
Then you would need to consider 16-bit modes too. E.g. use RGBA5658 if
screen is RGB565.
>   
>>> Everything my path does is:
>>>
>>> 1) Enriches grub-mkfont with ability to write (and debug with -vv) 
>>> pff3 (as I call it now) font format. There are 2 differences between
>>> pff2 and pff3 formats: FILE magic (PFF2 becomes PFF3) and DATA block
>>> entires size multiples by 8 (1bit -> 8bit). In other words PFF3 stores
>>> 8-bit alpha channel instead of 1-bit.
>>> And grub-mkfont will still be able to generate pff2, of course.
>>>
>>>   
>>>       
>> And by default grub-mkfont should generate not antialiased font for
>> performance reasons. But user or theme creator can choose to use
>> antialiased fonts if they wish.
>>     
>
> It's exactly the way my patch does it. AA is optional and used
> explicitly.
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]