New handling of privates [was: Re: xf86-video-intel 2.5 release planning]

[Eamon Walsh]

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

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