New handling of privates [was: Re: xf86-video-intel 2.5 release planning]
Tomas Carnecky
tom at dbservice.com
Fri Aug 1 04:40:51 PDT 2008
Eamon Walsh wrote:
> Attached is a privates.c where dixLookupPrivate has been reduced to a
> test + array index.
> The problem is that it needs to store the array index into the memory
> referenced by the "key" pointer. Currently there is no requirement on
> "key" other than being a unique value.
>
> So committing this requires some refactoring first. Basically turning
> "static DevPrivateKey foo = &foo" into "static int blah; static
> DevPrivateKey foo = &blah". After it's done it can be committed. Maybe
> even backported.
The way I read your code, each DevPrivateKey is a unique index, no two
keys can can have the same index, is that correct? While I corrected the
DevPrivateKey usages throughout the code, I saw that many extensions
allocate one private key per object type (eg. one key for screens, one
key for windows, one key for pixmaps etc). There are more then 160 (just
a quick grep) private keys, so there is the possibility that each
PrivateRec array will be 160 pointers long and only sparsely occupated.
Compiz does the private handling nicely, it keeps a per-object-type list
of indices. But that approach would have to change large parts of the API.
tom
More information about the xorg
mailing list