New handling of privates [was: Re: xf86-video-intel 2.5 release planning]
ewalsh at tycho.nsa.gov
Fri Aug 1 10:56:08 PDT 2008
Tomas Carnecky wrote:
> Lukas Hejtmanek wrote:
>> On Fri, Aug 01, 2008 at 01:40:51PM +0200, Tomas Carnecky wrote:
>>> 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.
>> I wondered why a hash structure cannot be used...
> I think it makes sense, for performance reasons, to use a simple array.
> The 160 are a bit exaggerated, not all keys will be active at the same
> time. And the number could be cut down by a) ripping old code out (dpms,
> xvidmode etc) and b) changing existing code to use less private keys
> (dri2 for example uses three private keys: screen, window and pixmap,
> damage even four!).
Yes, this consolidation should be done. I also have the OK from Peter
to remove some DIX-level keys associated with the MPX merge. And
lately, a lot of code has been dropped from master which has cut down on
the number of keys.
The 160 number mentioned above seems exaggerated - with just one DDX and
driver active it should be much less. But, since the lookup functions
are not inlined any more, it should be possible in the future to
implement a hash table or whatever mechanism. As long as the keys are
still unique values it will be backwards-compatible.
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency
More information about the xorg