Re: Antialiased fonts patch.

[address@hidden]

On Thu, Feb 11, 2010 at 7:30 AM, Michal Suchanek <address@hidden> wrote:
> On 26 January 2010 11:04, Evgeny Kolesnikov <address@hidden> 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
>
> Grub will never look and feel exactly as the OS unless you import
> GTK/QT, its themes, freetype, ...
>
>> 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.
>
> In fact I think that 4bit antialiasing should suffice. 16 tones of the
> same color should be more than enough for most cases. Still I am not
> sure that it will make the rendering really faster than 8bit AA.

By antialiasing it seems that you mean alpha channel.

Has anyone considered instead supersampling in the x-direction?  This
also results in anti-aliased text but in addition yields more accurate
kerning and on LCD displays can be used for sub-pixel rendering.  I'd
say 8x supersampling, but since LCD displays have three components
(R,G,B) 6x might be better.

>
> Only testing on various  real hardware can possibly answer the
> question if and when one of the methods is faster. I would even expect
> that none is overall faster and that system exist where either is.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>