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.
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
