grub-mkfont and DejaVu font problems

grub-mkfont and DejaVu font problems

[Evgeny K]

Hello!

I'm currently developing a path to font functionality of grub2. Anti-aliased
fonts (currently 8 bit AA, but probably sub-pixel AA for LCD too).

There is one problem with DejaVuSansMono*.ttf fonts. When I'm trying
to render glyphs with grub-mkfont's way, all of the glyphs are rendered
with baseline in the middle so glyph sticks to the top of the bitmap.

While "grub-mkfont -v -v" still able to show complete glyph (i.e. glyph
image is not truncated) in the grub menu glyphs overlaps.

FreeSans*.ttf (as example) does not have such problem.

Does anybody know what the problem with DejaVu family might be?

Best regards, Evgeny.

Re: grub-mkfont and DejaVu font problems

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Evgeny K wrote:
> Hello!
>
> I'm currently developing a path to font functionality of grub2. Anti-aliased
> fonts (currently 8 bit AA, but probably sub-pixel AA for LCD too).
>
> There is one problem with DejaVuSansMono*.ttf fonts. When I'm trying
> to render glyphs with grub-mkfont's way, all of the glyphs are rendered
> with baseline in the middle so glyph sticks to the top of the bitmap.
>
> While "grub-mkfont -v -v" still able to show complete glyph (i.e. glyph
> image is not truncated) in the grub menu glyphs overlaps.
>
> FreeSans*.ttf (as example) does not have such problem.
>
> Does anybody know what the problem with DejaVu family might be?
>
>   
Bug in grub-mkfont is fixed in latest trunk
> Best regards, Evgeny.
>
>
> _______________________________________________
> 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 --]

Antialiased fonts patch.

[Evgeny Kolesnikov]

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

Here is the path for anti-aliased fonts.

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.

2) Adds pff3 format parsing and drawing ability to font.c.
And of course pff2 still there; actually as you can understand 95% of
code is reused because of such a little differences in formats.

Drawing itself implemented pretty straightforward: on each glyph
drawing A channel (from glyph) and foreground color are converted to
RGBA buffer and then blended in RGBA_8888 mode.

As far as I understand writing custom blitter for now will not worth it
in terms of efficiency.

When I test it I was unable to see performance difference between 1-bit
fonts and my version. They both flickers a little.

Files affected: /font/font.c and /util/grub-mkfont.c.


[-- Attachment #2: font.c.diff --]
[-- Type: text/x-patch, Size: 5512 bytes --]

--- font.c	2010-01-22 16:52:54.980914210 +0600
+++ font.bak.c	2010-01-22 00:38:28.000000000 +0600
@@ -51,7 +51,6 @@
 
 struct grub_font
 {
-  grub_uint8_t version;
   char *name;
   grub_file_t file;
   char *family;
@@ -65,7 +64,6 @@
   grub_uint32_t num_chars;
   struct char_index_entry *char_index;
   grub_uint16_t *bmp_idx;
-  grub_uint8_t *glyph_bitmap_buffer;
 };
 
 /* Definition of font registry.  */
@@ -93,7 +91,6 @@
 
 /* Font file format constants.  */
 static const char pff2_magic[4] = { 'P', 'F', 'F', '2' };
-static const char pff3_magic[4] = { 'P', 'F', 'F', '3' };
 static const char section_names_file[4] = { 'F', 'I', 'L', 'E' };
 static const char section_names_font_name[4] = { 'N', 'A', 'M', 'E' };
 static const char section_names_point_size[4] = { 'P', 'T', 'S', 'Z' };
@@ -216,8 +213,6 @@
 static void
 font_init (grub_font_t font)
 {
-  font->version = 2;
-
   font->name = 0;
   font->file = 0;
   font->family = 0;
@@ -445,7 +440,6 @@
   struct font_file_section section;
   char magic[4];
   grub_font_t font = 0;
-  grub_uint8_t pff3 = 0;
 
 #if FONT_DEBUG >= 1
   grub_printf("add_font(%s)\n", filename);
@@ -495,15 +489,12 @@
   grub_printf("read magic ok\n");
 #endif
 
-  if (grub_memcmp (magic, pff2_magic, 4) != 0 && grub_memcmp (magic, pff3_magic, 4) != 0)
+  if (grub_memcmp (magic, pff2_magic, 4) != 0)
     {
       grub_error (GRUB_ERR_BAD_FONT, "invalid font magic %x %x %x %x",
                   magic[0], magic[1], magic[2], magic[3]);
       goto fail;
     }
-  else
-    if (grub_memcmp (magic, pff3_magic, 4) == 0)
-      pff3 = 1;
 
 #if FONT_DEBUG >= 3
   grub_printf("compare magic ok\n");
@@ -517,9 +508,6 @@
   font_init (font);
   font->file = file;
 
-  if (pff3 != 0)
-    font->version = 3;
-
 #if FONT_DEBUG >= 3
   grub_printf("allocate font ok; loading font info\n");
 #endif
@@ -621,9 +609,6 @@
                font->max_char_width, font->max_char_height,
                font->num_chars);
 #endif
-  
-  /* Font loaded. Create glyph to bitmap conversion buffer */
-  font->glyph_bitmap_buffer = grub_malloc (font->max_char_width * font->max_char_height * 4);
 
   if (font->max_char_width == 0
       || font->max_char_height == 0
@@ -752,10 +737,7 @@
           return 0;
         }
 
-      if (font->version == 3)
-        len = width * height;
-      else
-        len = (width * height + 7) / 8;
+      len = (width * height + 7) / 8;
       glyph = grub_malloc (sizeof (struct grub_font_glyph) + len);
       if (! glyph)
         {
@@ -806,7 +788,6 @@
       grub_free (font->name);
       grub_free (font->family);
       grub_free (font->char_index);
-      grub_free (font->glyph_bitmap_buffer);
       grub_free (font);
     }
 }
@@ -1079,59 +1060,29 @@
 
   glyph_bitmap.mode_info.width = glyph->width;
   glyph_bitmap.mode_info.height = glyph->height;
-
-  if (glyph->font->version == 3)
-    {
-      glyph_bitmap.mode_info.mode_type =
-        (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS)
-        | GRUB_VIDEO_MODE_TYPE_RGB | GRUB_VIDEO_MODE_TYPE_ALPHA;
-      glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_RGBA_8888;
-      glyph_bitmap.mode_info.bpp = 32;
-      glyph_bitmap.mode_info.bytes_per_pixel = 4;
-      glyph_bitmap.mode_info.pitch = glyph->width * 4;
-    }
-  else
-    {
-      glyph_bitmap.mode_info.mode_type =
-        (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS)
-        | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP;
-      glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED;
-      glyph_bitmap.mode_info.bpp = 1;
-
-      /* Really 1 bit per pixel.  */
-      glyph_bitmap.mode_info.bytes_per_pixel = 0;
-
-      /* Packed densely as bits.  */
-      glyph_bitmap.mode_info.pitch = glyph->width;
-
-      glyph_bitmap.mode_info.number_of_colors = 2;
-      glyph_bitmap.mode_info.bg_red = 0;
-      glyph_bitmap.mode_info.bg_green = 0;
-      glyph_bitmap.mode_info.bg_blue = 0;
-      glyph_bitmap.mode_info.bg_alpha = 0;
-    }
-
+  glyph_bitmap.mode_info.mode_type =
+    (1 << GRUB_VIDEO_MODE_TYPE_DEPTH_POS)
+    | GRUB_VIDEO_MODE_TYPE_1BIT_BITMAP;
+  glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED;
+  glyph_bitmap.mode_info.bpp = 1;
+
+  /* Really 1 bit per pixel.  */
+  glyph_bitmap.mode_info.bytes_per_pixel = 0;
+
+  /* Packed densely as bits.  */
+  glyph_bitmap.mode_info.pitch = glyph->width;
+
+  glyph_bitmap.mode_info.number_of_colors = 2;
+  glyph_bitmap.mode_info.bg_red = 0;
+  glyph_bitmap.mode_info.bg_green = 0;
+  glyph_bitmap.mode_info.bg_blue = 0;
+  glyph_bitmap.mode_info.bg_alpha = 0;
   grub_video_unmap_color(color,
                          &glyph_bitmap.mode_info.fg_red,
                          &glyph_bitmap.mode_info.fg_green,
                          &glyph_bitmap.mode_info.fg_blue,
                          &glyph_bitmap.mode_info.fg_alpha);
-
-  if (glyph->font->version == 3)
-    {
-      int i;
-      grub_uint8_t *pixel = glyph->font->glyph_bitmap_buffer;
-      for (i = 0; i < glyph->width * glyph->height; i++)
-        {
-          *pixel = glyph_bitmap.mode_info.fg_red; pixel++;
-          *pixel = glyph_bitmap.mode_info.fg_green; pixel++;
-          *pixel = glyph_bitmap.mode_info.fg_blue; pixel++;
-          *pixel = glyph->bitmap[i]; pixel++;
-        }
-      glyph_bitmap.data = glyph->font->glyph_bitmap_buffer;
-    }
-  else
-    glyph_bitmap.data = glyph->bitmap;
+  glyph_bitmap.data = glyph->bitmap;
 
   int bitmap_left = left_x + glyph->offset_x;
   int bitmap_bottom = baseline_y - glyph->offset_y;

[-- Attachment #3: grub-mkfont.c.diff --]
[-- Type: text/x-patch, Size: 8437 bytes --]

--- grub-mkfont.c	2010-01-22 15:01:47.664910782 +0600
+++ grub-mkfont.bak.c	2010-01-22 00:38:28.000000000 +0600
@@ -51,7 +51,7 @@
 
 enum file_formats
 {
-  PFN,
+  PF2,
   ASCII_BITMAPS 
 };
 
@@ -59,7 +59,6 @@
 #define GRUB_FONT_FLAG_NOBITMAP		2
 #define GRUB_FONT_FLAG_NOHINTING	4
 #define GRUB_FONT_FLAG_FORCEHINT	8
-#define GRUB_FONT_FLAG_8BIT_AA	4096
 
 struct grub_font_info
 {
@@ -95,7 +94,6 @@
   {"version", no_argument, 0, 'V'},
   {"verbose", no_argument, 0, 'v'},
   {"ascii-bitmaps", no_argument, 0, 0x102},
-  {"pff3", no_argument, 0, '3'},
   {0, 0, 0, 0}
 };
 
@@ -111,7 +109,6 @@
 Usage: %s [OPTIONS] FONT_FILES\n\
 \nOptions:\n\
   -o, --output=FILE_NAME    set output file name\n\
-  -3, --pff3                save in pff3 format (antialiased)\n\
   --ascii-bitmaps           save only the ASCII bitmaps\n\
   -i, --index=N             set face index\n\
   -r, --range=A-B[,C-D]     set font range\n\
@@ -157,12 +154,7 @@
   grub_uint8_t *data;
   int mask, i, j, bitmap_size;
   FT_GlyphSlot glyph;
-  int flag = FT_LOAD_RENDER;
-
-  if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA)
-    flag |= FT_LOAD_TARGET_NORMAL;
-  else
-    flag |= FT_LOAD_MONOCHROME;
+  int flag = FT_LOAD_RENDER | FT_LOAD_MONOCHROME;
 
   if (font_info->flags & GRUB_FONT_FLAG_NOBITMAP)
     flag |= FT_LOAD_NO_BITMAP;
@@ -193,11 +185,7 @@
   width = glyph->bitmap.width;
   height = glyph->bitmap.rows;
 
-  if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA)
-    bitmap_size = width * height;
-  else
-    bitmap_size = ((width * height + 7) / 8);
-   
+  bitmap_size = ((width * height + 7) / 8);
   glyph_info = xmalloc (sizeof (struct grub_glyph_info) + bitmap_size);
   glyph_info->bitmap_size = bitmap_size;
 
@@ -223,18 +211,13 @@
   if (glyph_info->y_ofs + height > font_info->max_y)
     font_info->max_y = glyph_info->y_ofs + height;
 
-  if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA)
-    memcpy (glyph_info->bitmap, glyph->bitmap.buffer, bitmap_size);
-  else
-    {
-      mask = 0;
-      data = &glyph_info->bitmap[0] - 1;
-      for (j = 0; j < height; j++)
-        for (i = 0; i < width; i++)
-          add_pixel (&data, &mask,
-		                 glyph->bitmap.buffer[i / 8 + j * glyph->bitmap.pitch] &
-		                 (1 << (7 - (i & 7))));
-    }
+  mask = 0;
+  data = &glyph_info->bitmap[0] - 1;
+  for (j = 0; j < height; j++)
+    for (i = 0; i < width; i++)
+      add_pixel (&data, &mask,
+		 glyph->bitmap.buffer[i / 8 + j * glyph->bitmap.pitch] &
+		 (1 << (7 - (i & 7))));
 }
 
 void
@@ -246,17 +229,18 @@
       grub_uint32_t j;
 
       for (i = 0; i < font_info->num_range; i++)
-	      for (j = font_info->ranges[i * 2]; j <= font_info->ranges[i * 2 + 1]; j++)
-	        add_char (font_info, face, j);
+	for (j = font_info->ranges[i * 2]; j <= font_info->ranges[i * 2 + 1];
+	     j++)
+	  add_char (font_info, face, j);
     }
   else
     {
       grub_uint32_t char_code, glyph_index;
 
       for (char_code = FT_Get_First_Char (face, &glyph_index);
-            glyph_index;
-	          char_code = FT_Get_Next_Char (face, char_code, &glyph_index))
-	      add_char (font_info, face, char_code);
+	   glyph_index;
+	   char_code = FT_Get_Next_Char (face, char_code, &glyph_index))
+	add_char (font_info, face, char_code);
     }
 }
 
@@ -308,74 +292,56 @@
 
       xmax = glyph->x_ofs + glyph->width;
       if (xmax < glyph->device_width)
-        xmax = glyph->device_width;
+	xmax = glyph->device_width;
 
       xmin = glyph->x_ofs;
       if (xmin > 0)
-        xmin = 0;
+	xmin = 0;
 
       ymax = glyph->y_ofs + glyph->height;
       if (ymax < font_info->asce)
-        ymax = font_info->asce;
+	ymax = font_info->asce;
 
       ymin = glyph->y_ofs;
       if (ymin > - font_info->desc)
-        ymin = - font_info->desc;
+	ymin = - font_info->desc;
 
       bitmap = glyph->bitmap;
       mask = 0x80;
       for (y = ymax - 1; y >= ymin; y--)
-	    {
-	      int line_pos;
+	{
+	  int line_pos;
 
-        line_pos = 0;
-	      for (x = xmin; x < xmax; x++)
-	      {
-	        if ((x >= glyph->x_ofs) &&
-               (x < glyph->x_ofs + glyph->width) &&
-               (y >= glyph->y_ofs) &&
-               (y < glyph->y_ofs + glyph->height))
-            {
-              if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA)
-                {
-                  if (*bitmap > 127)
-                    line[line_pos++] = '#';
-                  else if (*bitmap > 64)
-                    line[line_pos++] = '8';
-                  else if (*bitmap > 8)
-                    line[line_pos++] = 'o';
-                  else if (*bitmap > 1)
-                    line[line_pos++] = '-';
-                  else
-                    line[line_pos++] = '_';
-
-                  bitmap++;
-                }
-              else
-                {
-                  line[line_pos++] = (*bitmap & mask) ? '#' : '_';
-                  mask >>= 1;
-                  if (mask == 0)
-                    {
-                       mask = 0x80;
-                       bitmap++;
-                    }
-                }
-            }   
-	        else if ((x >= 0) &&
-		               (x < glyph->device_width) &&
-		               (y >= - font_info->desc) &&
-		               (y < font_info->asce))
-		        {
-              line[line_pos++] = ((x == 0) || (y == 0)) ? '+' : '.';
-		        }
-	        else
-		        line[line_pos++] = '*';
-	      }
-      line[line_pos] = 0; 
-      printf ("%s\n", line);
-	  }
-  }
+	  line_pos = 0;
+	  for (x = xmin; x < xmax; x++)
+	    {
+	      if ((x >= glyph->x_ofs) &&
+		  (x < glyph->x_ofs + glyph->width) &&
+		  (y >= glyph->y_ofs) &&
+		  (y < glyph->y_ofs + glyph->height))
+		{
+		  line[line_pos++] = (*bitmap & mask) ? '#' : '_';
+		  mask >>= 1;
+		  if (mask == 0)
+		    {
+		      mask = 0x80;
+		      bitmap++;
+		    }
+		}
+	      else if ((x >= 0) &&
+		       (x < glyph->device_width) &&
+		       (y >= - font_info->desc) &&
+		       (y < font_info->asce))
+		{
+		  line[line_pos++] = ((x == 0) || (y == 0)) ? '+' : '.';
+		}
+	      else
+		line[line_pos++] = '*';
+	    }
+	  line[line_pos] = 0;
+	  printf ("%s\n", line);
+	}
+    }
 }
 
 void
@@ -396,22 +362,22 @@
       if (glyph->width != 8 || glyph->height != 16)
       {
         /* printf ("Width or height from glyph U+%04x not supported, skipping.\n", glyph->char_code);  */
-        correct_size = 0;
+	correct_size = 0;
       }
       int row;
       for (row = 0; row < glyph->height; row++)
         {
-	        if (correct_size)
-	          fwrite (&glyph->bitmap[row], sizeof(glyph->bitmap[row]), 1, file);
-	        else
-	          fwrite (&correct_size, 1, 1, file);
+	  if (correct_size)
+	    fwrite (&glyph->bitmap[row], sizeof(glyph->bitmap[row]), 1, file);
+	  else
+	    fwrite (&correct_size, 1, 1, file);
         }
     }
-  fclose (file);
+    fclose (file);
 }
 
 void
-write_font_pfN (struct grub_font_info *font_info, char *output_file)
+write_font_pf2 (struct grub_font_info *font_info, char *output_file)
 {
   FILE *file;
   grub_uint32_t leng, data;
@@ -428,11 +394,7 @@
   leng = grub_cpu_to_be32 (4);
   grub_util_write_image ("FILE", 4, file);
   grub_util_write_image ((char *) &leng, 4, file);
-  if (font_info->flags & GRUB_FONT_FLAG_8BIT_AA)
-    grub_util_write_image ("PFF3", 4, file);
-  else
-    grub_util_write_image ("PFF2", 4, file);
-  
+  grub_util_write_image ("PFF2", 4, file);
   offset += 12;
 
   if (! font_info->name)
@@ -562,7 +524,7 @@
   int font_index = 0;
   int font_size = 0;
   char *output_file = NULL;
-  enum file_formats file_format = PFN;
+  enum file_formats file_format = PF2;
 
   memset (&font_info, 0, sizeof (font_info));
 
@@ -573,7 +535,7 @@
   /* Check for options.  */
   while (1)
     {
-      int c = getopt_long (argc, argv, "bao:n:i:s:d:r:hVv3", options, 0);
+      int c = getopt_long (argc, argv, "bao:n:i:s:d:r:hVv", options, 0);
 
       if (c == -1)
 	break;
@@ -670,10 +632,6 @@
 	  case 0x102:
 	     file_format = ASCII_BITMAPS;
 	     break;
-	     
-	  case '3':
-        font_info.flags |= GRUB_FONT_FLAG_8BIT_AA;
-        break;
 
 	  default:
 	    usage (1);
@@ -739,8 +697,8 @@
 
   FT_Done_FreeType (ft_lib);
 
-  if (file_format == PFN)
-    write_font_pfN (&font_info, output_file);
+  if (file_format == PF2)
+    write_font_pf2 (&font_info, output_file);
   else if (file_format == ASCII_BITMAPS)
     write_font_ascii_bitmap (&font_info, output_file);
 

Re: Antialiased fonts patch.

[BVK Chaitanya]

Can you send us a screenshot? :)


-- 
bvk.chaitanya

Re: Antialiased fonts patch.

[Evgeny Kolesnikov]

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

> Can you send us a screenshot? :)

Here it is. DejaVu, no hinting.



[-- Attachment #2: Screenshot-Karmic [Running] - VirtualBox OSE.png --]
[-- Type: image/png, Size: 31520 bytes --]

Re: Antialiased fonts patch.

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Evgeny Kolesnikov wrote:
> Here is the path for anti-aliased fonts.
>
>   
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? 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?
> 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.
> 2) Adds pff3 format parsing and drawing ability to font.c.
> And of course pff2 still there; actually as you can understand 95% of
> code is reused because of such a little differences in formats.
>
> Drawing itself implemented pretty straightforward: on each glyph
> drawing A channel (from glyph) and foreground color are converted to
> RGBA buffer and then blended in RGBA_8888 mode.
>
> As far as I understand writing custom blitter for now will not worth it
> in terms of efficiency.
>
>   
> When I test it I was unable to see performance difference between 1-bit
> fonts and my version. They both flickers a little.
>
> Files affected: /font/font.c and /util/grub-mkfont.c.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 --]

Re: Antialiased fonts patch.

[Evgeny Kolesnikov]

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.

> 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 (BURG project is already interested in - Bean, help
me :)). 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.

> > 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.

Re: Antialiased fonts patch.

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: Antialiased fonts patch.

[Carles Pina i Estany]

Hi,

On Jan/26/2010, Vladimir '??-coder/phcoder' Serbinenko wrote:
> Evgeny Kolesnikov wrote:

> > 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.

how much slower would be? (just for curiosity). 10 ms per screen or 20
seconds?

> Perhaps we can have a variable:
> set i_want_to_waste_time_in_booter=yes

I suggest "set i_want_high_quality_fonts=yes" (well, withought i_want).
I would say that mainly everybody knows that "high quality something"
usually has some payback.

> 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.

I understand and agree.

-- 
Carles Pina i Estany
	http://pinux.info

Re: Antialiased fonts patch.

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Any news on this one?
> 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. 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.
>   
Basically the general idea is to make whatever is looped through is as
fast as possible and to decrease the number of iterations. E.g: put
conditions outside of the loops, use 32-bit accesses instead of 8-bit
ones (don't forget to check that uint32_t is 4-byte aligned) and don't
use higher quality buffer if you're going to blit it on lower quality.
Last rule isn't respected in grub2 (unfortunately). Of course exceptions
to rules can be discussed especially in eye-candy mode

I would prefer to make new version magic PFF3  and add a flag field in
version = 3 and GRUB_FONT_8_BIT would be the first flag. This allows
further expandability by orthogonality.
I started reviewing your patch but it turned out that it's a patch
bewtween some kind of your local versions. Could you send a patch
against trunk?

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



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

Re: Antialiased fonts patch.

[Michal Suchanek]

On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> 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.

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

Re: Antialiased fonts patch.

[richardvoigt]

On Thu, Feb 11, 2010 at 7:30 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Antialiased fonts patch.

[Evgeny Kolesnikov]

On Fri, 2010-02-12 at 00:21 -0600, richardvoigt@gmail.com wrote:
> On Thu, Feb 11, 2010 at 7:30 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
> > On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> wrote:
> >> Hi,
> >>
> >>> At first I was completely against antialiasing support because of
> ...
> > 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.

Sub-pixel AA is in progress.

Re: Antialiased fonts patch.

[Evgeny Kolesnikov]

On Thu, 2010-02-11 at 14:30 +0100, Michal Suchanek wrote:
> On 26 January 2010 11:04, Evgeny Kolesnikov <evgenyz@gmail.com> wrote:
> > 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, ...

GTK and QT uses FT for rendering fonts. Actually almost everything in
linux desktop uses FT.

grub-mkfont also uses FT to render common fonts formats into the PF2(3)
format.

So, GRUB2 will look and feel _exactly_ like GTK/QT in terms of
_font_rendering_. Controls and other theming is out of scope of this
patch and entire GRUB2 I suppose. Anyway - everything in QT/GTK is the
bitmaps, drawn in some order. GRUB2 understands alpha channels in
bitmaps, so everything is in the hands of GRUB2 theme designer.

> > 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.
> 
> 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.

If we really care about speed we should use 1-bit fonts. Nothing can be
faster. And 1-bit fonts will stay here.

But if we care about eye-candy view, we should not throw away any bits
from FT library result. This will not be fast enough to replace 1-bit
fonts, and it will differ from other desktop apps. So, what the profit?

You also may concern about font size itsef (15-30 Mb for sub-pixel AA),
but who really care about it when 1 Tb HDD costs less than 100$? Also we
can gzip entire font file later if it will really be the problem.

Re: Antialiased fonts patch.

[Bruce Dubbs]

Evgeny Kolesnikov wrote:

> If we really care about speed we should use 1-bit fonts. Nothing can be
> faster. And 1-bit fonts will stay here.
> 
> But if we care about eye-candy view, we should not throw away any bits
> from FT library result. This will not be fast enough to replace 1-bit
> fonts, and it will differ from other desktop apps. So, what the profit?
> 
> You also may concern about font size itsef (15-30 Mb for sub-pixel AA),
> but who really care about it when 1 Tb HDD costs less than 100$? Also we
> can gzip entire font file later if it will really be the problem.

Actually I don't understand why AA fonts are needed for a screen that 
most users will look at for about 3 seconds to select their OS and boot.

I suspect most distros will set up grub to skip the GRUB screen completely.

Is the effort worth the cost?  I suppose doing it 'because you can' or 
because someone is 'scratching and itch' is OK, but I don't think it 
should be a major consideration.

   -- Bruce

Re: Antialiased fonts patch.

[Evgeny Kolesnikov]

On Fri, 2010-02-12 at 01:20 -0600, Bruce Dubbs wrote:
> Evgeny Kolesnikov wrote:
> 
> > If we really care about speed we should use 1-bit fonts. Nothing can be
> > faster. And 1-bit fonts will stay here.
> > 
> > But if we care about eye-candy view, we should not throw away any bits
> > from FT library result. This will not be fast enough to replace 1-bit
> > fonts, and it will differ from other desktop apps. So, what the profit?
> > 
> > You also may concern about font size itsef (15-30 Mb for sub-pixel AA),
> > but who really care about it when 1 Tb HDD costs less than 100$? Also we
> > can gzip entire font file later if it will really be the problem.
> 
> Actually I don't understand why AA fonts are needed for a screen that 
> most users will look at for about 3 seconds to select their OS and boot.
> 
> I suspect most distros will set up grub to skip the GRUB screen completely.
> 
> Is the effort worth the cost?  I suppose doing it 'because you can' or 
> because someone is 'scratching and itch' is OK, but I don't think it 
> should be a major consideration.

I can ask you only one thing: Bruce how your apartment's door is looks
like? Is it a piece of rusted metal plate with number scratched out with
screwdriver on it and wire soldered to use as handle? You use it only
for reaching you home, 3-6 seconds (if you not drunk like a fish, of
course :)...

Anyway AA fonts completely optional.

Re: Antialiased fonts patch.

[Michal Suchanek]

On 12 February 2010 08:20, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
> Evgeny Kolesnikov wrote:
>
>> If we really care about speed we should use 1-bit fonts. Nothing can be
>> faster. And 1-bit fonts will stay here.
>>
>> But if we care about eye-candy view, we should not throw away any bits
>> from FT library result. This will not be fast enough to replace 1-bit
>> fonts, and it will differ from other desktop apps. So, what the profit?

I personally don't want antialiasing to make grub pixel equivalent of
desktop applications but to get usable fonts at sizes different from
16px (or whatever unifont uses as it's the only fairly complete bitmap
font we have).

It turns out that rendering TrueType fonts into 1bit bitmaps yields
glyphs that are ugly and in some cases quite unreadable. If 4bit
bitmap improves this situation enough that we can get fonts of
different sizes that don't cause people run away in horror then 4bits
are good enough for me.

>>
>> You also may concern about font size itsef (15-30 Mb for sub-pixel AA),
>> but who really care about it when 1 Tb HDD costs less than 100$? Also we
>> can gzip entire font file later if it will really be the problem.
>
> Actually I don't understand why AA fonts are needed for a screen that most
> users will look at for about 3 seconds to select their OS and boot.
>
> I suspect most distros will set up grub to skip the GRUB screen completely.
>
> Is the effort worth the cost?  I suppose doing it 'because you can' or
> because someone is 'scratching and itch' is OK, but I don't think it should
> be a major consideration.
>

There are two reasons. First you cannot make a stylish boot screen
with only single bitmap font. With grub legacy it turned out that some
people would care enough that they would fork the bootloader just to
get that so it is better if we can provide the feature in the main.

The other reason is that in some cases you will see the grub menu for
more than a few seconds. Some installation/live CDs would need to
provide help texts and option selections before the system boots
because selecting some options is vital for the system to booting at
all on some hardware.

Thanks

Michal

Re: Antialiased fonts patch.

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Evgeny Kolesnikov wrote:
>> I would prefer to make new version magic PFF3  and add a flag field in
>> version = 3 and GRUB_FONT_8_BIT would be the first flag. This allows
>> further expandability by orthogonality.
>>     
>
> I used PFF3 magic for 8-bit and PFF4 for 24-bit (sub-pixel).
>
>   
Please use PFF3 and feature bitfield




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



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

Re: Antialiased fonts patch.

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Bruce Dubbs wrote:
> Evgeny Kolesnikov wrote:
>
>> If we really care about speed we should use 1-bit fonts. Nothing can be
>> faster. And 1-bit fonts will stay here.
>>
>> But if we care about eye-candy view, we should not throw away any bits
>> from FT library result. This will not be fast enough to replace 1-bit
>> fonts, and it will differ from other desktop apps. So, what the profit?
>>
>> You also may concern about font size itsef (15-30 Mb for sub-pixel AA),
>> but who really care about it when 1 Tb HDD costs less than 100$? Also we
>> can gzip entire font file later if it will really be the problem.
>
> Actually I don't understand why AA fonts are needed for a screen that
> most users will look at for about 3 seconds to select their OS and boot.
>
> I suspect most distros will set up grub to skip the GRUB screen
> completely.
>
> Is the effort worth the cost?  I suppose doing it 'because you can' or
> because someone is 'scratching and itch' is OK, but I don't think it
> should be a major consideration.
>
I agree with you. Same is true for the whole gfxmenu. However for some
esoteric reasons people care.
But on the other hand anitaliasing may improve readability of complex
rendered system e.g. diacritics, vowel marks and Indic scripts
>   -- Bruce
>
>
> _______________________________________________
> 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 --]