[cairo] [patch] caching, glyph, font, and glyphset patch, round 2

[Keith Packard]

Around 0 o'clock on Oct 7, graydon hoare wrote:

+ * This table is open-addressed with double hashing. the secondary hash
+ * function is rounded up to an odd number and the table is a power of two
+ * in size. These assumptions ensure that the table is fully searched; if
+ * you want to experiment with different hash functions, there is
+ * conditional machinery in place for measuring performance.

I believe this comment is incorrect now, right?

> +static cairo_cache_entry_base_t *dead_entry = &dead_structure;;

<pedantic>Extra semi colon.</pedantic>

<micro-optimization>
I might also use a (semi-)kludge to avoid a memory reference:

	#define DEAD_ENTRY	((cario_cache_entry_base_t *) 1)

If this is too stomach-turning, perhaps:

	#define dead_entry (&dead_structure)

The latter places a larger burden on the loader than the former as it will
add relocation entries every place the value is used, and use longer 
instructions for the unknown value. 

</micro-optimization>

+    new_size = tmp.arrangement->size;
+    tmp.entries = malloc (new_size * sizeof (cairo_cache_entry_base_t *));
+    if (tmp.entries == NULL) 
+	return CAIRO_STATUS_NO_MEMORY;
+    
+    memset (tmp.entries, 0, (new_size * sizeof (cairo_cache_entry_base_t *)));
...
+	cache->entries = malloc (sizeof(cairo_cache_entry_base_t *) * 
+				 cache->arrangement->size);
+	if (cache->entries == NULL)
+	    return CAIRO_STATUS_NO_MEMORY;
+	memset (cache->entries, 0, (sizeof(cairo_cache_entry_base_t *) * 
+				    cache->arrangement->size));

These seem like a good opportunities to use calloc which needn't call memset 
for newly mmap'ed pages.

+    /* FIXME: this doesn't do vertical layout atm. */
+    extents->max_y_advance = 0.0;

The application must request vertical layout somehow.  I suggest that 
perhaps cairo not worry about this and leave that kind of complexity to
an upper level library like Qt or Pango.

It seems like we should be able to add sub-pixel glyph rendering at this 
point.  Is that true?

+    XRenderCompositeText32 (self->dpy,
+			    _render_operator (operator),
+			    src->picture,
+			    self->picture,
+			    g->a8_pict_format,
+			    source_x, source_y,
+			    0, 0,
+			    elts, num_glyphs);

I'm wondering if there's a way to use 8 or 16 bit values for glyphs; for 
some applications, quadrupling the size of glyph information will 
measurably impact network utilization.   Perhaps we just don't care, 
expecting that gzip will be able to compress this down in most cases.

To do so would necessitate the use of multiple glyphsets.  Is this 
possible?  Can we retro fit this later?

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041007/bc77c144/attachment.pgp