[PULL v2] XResource extension v1.2

[Erkki Seppala]

Hello,

On 14.03.2011 22:35, Keith Packard wrote:
> We've already got half a dozen hash table implementations in the X
> server, most of which are heavily tuned for a particular task.

Yes, there are some hash implementations which are intertwined with the
implementation of the code using it, such as with resources (which is
what I wanted to avoid, to make the actual implementation more clear),
and then there is x-hash.{c,h} in hw/xquartz/xpr, which seemed quite
un-Xish, given its dependency on a a separate linked list implementation
in x-list (which features thread-safe freelists).

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

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

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

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

>> Rami Ylimäki (3):
>
>> render: Report pixmap usage of pictures to resource extension.
>> composite: Report pixmap usage of client windows to resource
>> extension.
>
> This patch is out-of-sequence -- it uses LookupResourceType which
> isn't defined at this point.

Oops, I have quite likely messed up the order while updating the patches
in my tree.

>> dix: Add reverse resource name lookup function to registry.
>
> Ick. The names are purely informative, if you need the resource type,
> then export the necessary variable.

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