[PULL v2] XResource extension v1.2

[Keith Packard]

On Tue, 15 Mar 2011 10:42:32 +0200, Erkki Seppala <erkki.seppala at vincit.fi> wrote:

> I quite hope that there will be more standard data structures in X,
> because not having them leads to having ad-hoc data structures that are
> possibly suboptimal for the task at hand - not only performance-wise but
> from code clarity point of view as well. I think that having this
> implementation doesn't at least make the situation worse ;).

I'd say it would be better to separate out the tasks of adding this new
code from that of standardizing on one hash API. I don't expect you to
work on fixing the rest of the server, but until we've got at least two
existing hash users sharing the same implementation, let's leave your
hash code out of DIX and hope that someday someone merges all of these
implementations together.

> Glib appears to be somewhat popular and have a decent set of data
> structures, but I imagine not everyone would be happy with a new
> dependency. (Disclaimer: I haven't actually used Glib.)

Glib has an incompatible license, and so isn't a good candidate here.

> While the current implementation of the hash table in the patch is far
> from optimal, it can be enhanced should there be more high-profile uses
> for it. For example it allocates multiple blocks when one could do (with
> some alignment etc related calculations).

You might take a look at the hash implementation in the Render glyph
code; it's one of my favorites as it avoids the overhead of per-bucket
linked lists.

> >> dix: add reference count of the resource to ResourceSizeRec
> >
> > This seems to be used (at present) only for pixmaps. And, pixmaps
> > can be referenced by many things. Is there some specification for
> > which references are included in this count?
> 
> The specification is that the best effort is made to find as many
> references as possible.

Ok, it should at least be bigger when you have a pile of pictures or GCs
pointing at a single pixmap.

> I discussed this with Rami and that solution is fine. I shall update the
> code.

Less code is good code :-)

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110315/ed0984da/attachment.pgp>