9bd2012df7
With ItemInfoPackages we now can have a buffered, static global translation table from SlotIDs to WhichIDs since the ItemInfoStatic used already contains all the needed information. Register that in registerItemInfoPackage at the Pool and use it for lookup. That speeds up the lookup from O(n) to O(1). Since that lookup is used in UI and UNO API implementations this has positive effect on load/safe, but also all interactive stuff in the whole office. NOTE: I tried to use a merged version of that translation table in the parent pool, but this shows double SlotIDs, what is no wonder since that's what those are used for: To get different WhichIDs for a SlotID in Item handling. This *might* prevent getting rid of the chanined Pools at all - sadly. The returned WhichID directly depends on which Pool the function(s) GetWhichIDFromSlotID and GetTrueWhichIDFromSlotID are called. NOTE: Very strange is that the parameter 'bDeep' in that functions is *not* passed down to the call to the secondary Pool - probably an error, but risky to fix, that may change already the behaviour :-( Change-Id: Iea77ffad0f6a5401ab74fea0bbfc2589c66680ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163597 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> |
||
|---|---|---|
| .. | ||
| abpilot | ||
| activex | ||
| bibliography | ||
| config | ||
| dbpilots | ||
| inc | ||
| logging | ||
| macosx/spotlight | ||
| ole | ||
| propctrlr | ||
| scanner | ||
| update | ||