summaryrefslogtreecommitdiff
path: root/include/svl
AgeCommit message (Collapse)Author
2024-07-29tdf#161846 use unordered_map in SfxItemPropertyMapNoel Grandin
with large property maps, even a binary search starts showing up, but we can do a O(1) search here by using a map Change-Id: Ie7916076073e6dd393f0a1fb5a0db1b973999408 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171173 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-29use more GetItemSurrogatesForItemNoel Grandin
since it is considerably more efficient Change-Id: I224ff890f6dd52481621b46f912f1e8dbf65126c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171182 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-29tdf#161875 buffer NameOrIndex Items for fast SurrogatesArmin Le Grand (Collabora)
Problem is that collecting the Items using the ItemSets and PoolItemHolders is too expensive when used too often. For read-only access it is okay to have the Items directly registerd (for write access we *need* the ItemSets and PoolItemHolders, see iterateItemSurrogates). This is limited to Items which need to support surrogates, but can further be limited to the here critical ones - the ones derived from NameOrIndex. This is done here by checking if the Item is a NameOrIndex based one by adding a bool to the item that gets set in the NameOrIndex constructor. If needed this can be changed, e.g. by using besides the SFX_ITEMINFOFLAG_SUPPORT_SURROGATE another flag signaling this. Since only Items that are currently held by an ItemSet or a PoolItemHolder get registered it is not necessary to change the Item's RefCount in any way, doing that may lead (again, we had that with directly set Items at the Pool in the past) to long-living Items that only get cleaned-up when the pool/ document gets destructed. This buffering is now SfxItemType-based, no longer using the WhichID, so the result needs to be checked for WhichID additionally - if needed (?). All in all it's anyways a compromize, every usage of the surrogate mechanism is a 'hack' in the sense that for lazy reasons not the model data is traversed directly, but assumed that all Items set at a pool/model *are* model/document data (what is not always true). CheckNamedItem does not need to be static, changed that. Also all accesses to maRegisteredNameOrIndex *have* to work on the MasterPool instance, same as buffered ItemSets or PoolItemHolders, corrected that, too. Number of instances in the buffer need to be counted, else an instance will be removed too early: The same instance of an Item can be referenced by multiple sets/holders, so the first remove from the buffer would already remove even when the Item is referenced multiple times. Added that. Added more asserts & made sure that all constructors/ destructors of SfxItemSet do take care of registering Items for the surrogate mechanism as needed. Change-Id: Ib33e7f0bd4abd32a3bb68278f33b0abb9a4754c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171084 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-26fix in some missing SfxItemTypesNoel Grandin
Change-Id: I7dcb9768a8cd63200b8f8c50d8170e78ff5aeec2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171068 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-22Improve the perf for pool item scanning..Noel Grandin
for large complex documents with lots of shapes. When that happens, we spend a lot of time scanning the std::unordered_set inside DefaultItemInstanceManager. Since most of our items are already capable of being hashed, and thus avoiding the scanning cost, make it so we can use the HashableItemInstanceManager most of the time. Change-Id: I43f4c04e956d316c976bea67d1941529d2d91182 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170813 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Tested-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-18Fix typoAndrea Gelmini
Change-Id: Idaa3bb659133a9bc4d9253d814ab3026ee784af7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170503 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Jenkins
2024-07-15ITEM: secure HashedItemInstanceManagerArmin Le Grand (allotropia)
This one still used just a hash to feed a unordered_map what is not safe. Changed to unordered_set and added hash and equal operators. Change-Id: I2a426c449536747ad59f8bd8781a7eadceea9183 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170417 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-11ITEM: replaced typeid/hash_code with SfxItemTypeArmin Le Grand (allotropia)
for the ItemInstanceManager the identification was done using typeid/hash_code, but that has problems - it is only defined to be identical for two instances of the same type, but other types can have the same code. Thanks to Noel to find that out, that is not reliable to be used. In the meantime we have SfxItemType to identify Item instances, so I changed the code to use that. The master had five additionally added Items that use the (2a) method of this mechanism (see comments in svl/source/items/globalpool.cxx for that). The gloal is to use as less as possible of this Items in that mechanism, so I checked. For four of these hashing was used, so the mem/runtime aspect is okay -> access is fast enough to prefer mem over runtime. Adding hashed Items (or any other fast mechanism) is always okay. One did not have that (SvxBoxItem) and used just the fallback ItemInstanceManager, so I removed it. We now have 18 Items for which that mechanism is initialized immediately. Noel also already moved the countdown for starting to use the mechanism in case of default handling (case (1), NUMBER_OF_UNSHARED_INSTANCES) to the unorderd_set. someting I had already planned to do, too - thanks! Change-Id: Icf6f427e5ea64672f385357aaad75bb5b7fcbf98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170314 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-07-09Revert "fix and simplify the ItemInstanceManager mechanism"Noel Grandin
This reverts commit 85fd526fc681a994415bb422090d1d23aa7d54f6. Change-Id: I5019f72f88497f50a77666d57f2d16c2749bd1c9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170218 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-09loplugin:unusedenumconstantsNoel Grandin
Change-Id: Ifd22f5cc618137d715f78f0a04550256987752ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170186 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-08make some of the SfxStringItem subclasses hashableNoel Grandin
Change-Id: I7ad748b67266926f1e4e67e843a90b5ac3fe58b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170152 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-06tdf#161717 Enhancement to identify click on tracked change in theJim Raykowski
document by highlighting the corrosponding entry in the "Manage Changes" dialog and sidebar panel Change-Id: I1f31580a4fe764dd800c6db1e9a4e2024db14c6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169692 Reviewed-by: Jim Raykowski <raykowj@gmail.com> Tested-by: Jenkins
2024-07-05fill in more SfxItemType valuesNoel Grandin
found by doing some git grepping, we should now have values for all items in the hierarchy Change-Id: I397ca7e8f53f53737201385c4c8029b436895c1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170016 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-07-05fix asan buildNoel Grandin
after commit 85fd526fc681a994415bb422090d1d23aa7d54f6 "fix and simplify the ItemInstanceManager mechanism" The problem is that some *Item classes in sw/ and sc/ share WhichIds, and a whole bunch of SfxBoolItem subclasses share the same SfxItemType enum value. So we ended up mixing and matching objects of different concrete subclasses in a given *ItemManager collection. Add some asserts to the global pool code to catch issues like this earlier on. Add unique value of the SfxItemType enum for all the SfxBoolItem subclasses Change-Id: I3c8d4e02be1cd412b0292e973a6498df5f8e7102 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170003 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-03fix and simplify the ItemInstanceManager mechanismNoel Grandin
The mechanism is currently broken because it uses hash values as keys, in two different places. But hash values are not required to be unique, and as soon as there are enough items of a given type, a collision is inevitable. So just simplify this whole mechanism. There is no reason we need type-specific item managers. Stuff everything into a single global pool, that uses hashing correctly. Notes (*) Performance, as far as I can tell, is the same or slightly better. (*) I removed the NUMBER_OF_UNSHARED_INSTANCES thing, in favour of just having a simpler mechanism Change-Id: I9068baf9bf6fae2500ae5748c6d1aabe6c3a18a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169709 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-06-28use more ASSERT_CHANGE_REFCOUNTED_ITEMNoel Grandin
which did I not see when I did commit cb3c65fb706cb1c7c9224222fd16875e924a9759 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Thu Jun 27 19:24:28 2024 +0200 assert when SfxObjectItems are modified while in a pool Change-Id: I16e2ee72eda4b3ca69f83eb70ad4f4b0a14748a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169696 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-06-28assert when SfxObjectItems are modified while in a poolNoel Grandin
which has always been a problem, but becomes a more obvious problem when I implement some upcoming optimisations Change-Id: I8b0368b0b8e9a726c71d241841afeed3876281d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169657 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-06-27reduce boilerplate code for type-specific ItemInstanceManagersNoel Grandin
create a template class to reduce repetition Change-Id: I8c9c71fdfdac20a3b34432affac07aa1d46e8373 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169613 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-06-26speed up DefaultItemInstanceManagerNoel Grandin
we can store the registered items in a map indexed by which-id, and avoid most of the search cost Change-Id: Ib3fbed436bc034e603819cfef8223dcc77eb7f06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169528 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-06-20tdf#144208 speedup doc with lots of redline(13)Noel Grandin
Add a custom method to SfxItemSet, to avoid some of the function calling overhead in a hot loop Change-Id: I525c9a696af941c6e39aa1677eb2a85f69c621bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169271 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-06-18Add SfxItemType to SfxPoolItemOliver Specht
The SfxPoolItem has a new member SfxItemType m_eItemType to compare types based on enums instead of typeinfo() which consumes a lot of time e.g. while AutoFormat is running Change-Id: I033ce67bc9a28ee4790f162380314de85fb4154e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166452 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-06-17cid#1603617 Big parameter passed by valueCaolán McNamara
and ~20 of similar warning The current size of SfxItemSet is 144 bytes, and std::function is 32 bytes of that. If we reintroduce Changed as a virtual method we can avoid the need for this callback. All of the calculation work that was originally unconditionally done, and then thrown away, was moved into the specific SwAttrSet case of this so the other normal cases don't do any wasted work anymore. Change-Id: Ieec90f6d28dad8a6bf1cf8f402042812bd81c331 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168967 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-06-11ITEM: Change SfxItemSet to use unordered_setArmin Le Grand (allotropia)
With all the changes done for Items we can now do deeper basic changes to the ItemSet itself with manageable risk. I already did https://gerrit.libreoffice.org/c/core/+/166455 aka 'ITEM: Add measurements for SfxItemSet usages' to get some statistical information about the fill/usage grade of the ItemSet's fixed PtrArray to SfxPoolItems, check that out to get an own picture. Those results show that an average usage is between some extremes ranging from 0% to 50%, but when using more checks and using multiple files/interactions/edits in all applications we end up with around typical 12%-19% of that array used, the rest is nullptr's. Thus I thought about one of the initial ideas of this series of changes (ITEM), to use a std::unordered_map (A) instead of that fixed array of SfxPoolItem Ptr's (B). Tthat again was for a complete type-based rewrite, which I once did a POC, but the code cannot be adapted to that, just too much work. Those are very different in architecture, (B) is done since a long time (since ever), but as pointed out above, (A) is now possible. There are many aspects to it, let's grep some: Speed (iterate): (A) and (B) are both linear. (A) has less entries, but may touch different mem areas (buckets). (B) is linear, but many empty spaces which are usually uselessly iterated. Speed (access Item by WhichID): (A) is hashed by WhichID, so mostly linear for unordered_set/hash. (B) is in a linear array, but has to calculate the offset for each WhichID access. So I guess speed will mostly equal out. Memory: (A) will be dynamically allocated (buckets), but stl is highly optimized and may even re-use areas, has to provide some extra info but will need less places for Items since it's dynamic and can start empty. (B) will be allocated once (except AllItemSet) and may even be 'derived' to the ItemSet (SfxItemSetFixed), but has to allocate all space at once. I can go in lots of more detail here, but due to the results of the statistics I just made a test now, including measuring some results (will include in gerrit, not here). I used two pro versions for that. That way I have some data now. Result is: - It is now possible to do this, it runs stable :-) - Speed: As expected, mostly no change - Memory: Depending on usage, 0% to 25% less, usually around 8-10% Side effects: - SfxAllItemSet could be done without WhichRanges, thus without expensive 'merges' - SfxItemSetFixed is not needed. While the idea is good, it needs a lot of extra stuff - Access to Items is linear if set - WhichRanges: Still needed, but for vaildity checking/filtering of ItemSet content - WhichRanges: Worth to think about if these are needed at all, probably just exist for historical reasons since allocation/number of added Items was never ever dynamic -> just not allocatable Putting the current version on gerrit, may still trigger some UTs (checked SW/SC/SD...) I did not like that functionality at ItemSet that hands out a vector of the set items for cases where to avoid iterating and deleting items at the same time at an ItemSet, so changed to using a local vector of remembered WhichIDs and deleting after the iterator is done. I also saw some strange usages of SfxItemIter in sw which i will have to check. Since there are still problems with UTs which I can not reproduce locally I have now added asserts to the case that an ItemSet gets changed with still having active SfxItemIter(s). That is always an error, but with the architecture of that fixed array of ItemPtrs did not have devastating effects (purely by coincidence). With that asserts, UTs run well in SC and SD, but in SW I get 11 (eleven!) asserts from the UTs, all of them from 'ITEM: SfxItemSet ClearItem' BTW. I guess these have to be fixed before thinking about this change... Good news is that all 11 cases were the same in SW, in SwHistorySetAttrSet::SwHistorySetAttrSet which does some strange things using two SfxItemIter in parallel. Thus SW UTs are also clear and I see no more errors caused by ItemSets being changed while SfxItemIters are alive. Bad news is that I still have errors to hunt... NOTE: Have now cleaned all UTs, this showed that there are some unexpected side-effects of the Items being processed in another order when SfxItemIter is used, also found one case where a WhichRangesContainer is constructed for a SfxItemSet using the set items from another ItemSet and SfxItemIter to do so. There *might* be more cases not covered by UTs. NOTE: While speed stays the same and mem is reduced up to 25% (see measurements in 1st comment) another *important* aspect is that this frees the way for using ItemSets *without* WhichRanges - these are necessary mainly to create that fixed array of pointers to the Items in a *manageable* size. With a dynamic structure like unordered_set there is in principle *no need* anymore to use WhichRanges to pre-define the Items a Set could hold. There is one exception: We have cases where one ItemSet is set at another one with defined WhichRanges to *filter* the contained Items - these would have to be identified. This is a rare case and we would have to check cases where an ItemSet gets set at another ItemSet. This would be as if all ItemSets would be AllItemSets in principle - much easier for everyone. NOTE: Waited for 24.8 split just to not take unnecessary risks. Change-Id: I75b0ac1d8a4495a3ee93c1117bdf618702785990 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166972 Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Jenkins
2024-06-06Resolves: tdf#161430 reindex the correct style if there are duplicate namesCaolán McNamara
Change-Id: I6d4e96faef3ec6caa038edf7595f91f20d964807 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168479 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-30avoid some dynamic_cast in SwTextFrameNoel Grandin
Change-Id: Ib73063871472727f27b552b1074d9d3872269b44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168231 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-29avoid dynamic_cast in SwCursorShellNoel Grandin
Change-Id: Ic66c427f5096aea53d6634874d98620dd91744b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168165 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-29avoid dynamic_cast in SwTOXBaseNoel Grandin
Change-Id: Iac8f502bf200f599d44f52504a3b70a1a21b370b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168164 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-29avoid dynamic_cast in SwTextNodeNoel Grandin
Change-Id: Id7ee5e922b7e99d1f3bade3b94285283eb07ae68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168163 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-28avoid dynamic_cast in ModifyChangedHintNoel Grandin
Change-Id: I78d9fc4984bf4313222c943816f81d31924dff26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168133 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-28avoid dynamic_cast in SwXRedlineNoel Grandin
Change-Id: Id39e34c0f1b68639d3adf0092d753cb5dfb4cb0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-28avoid dynamic_cast in PostItMgrNoel Grandin
Change-Id: Ieb571b8f39de1ffbc5cf1ce257204dca9bdb649e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168121 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-28avoid dynamic_cast in SwView::NotifyNoel Grandin
Change-Id: Id2b8f0f85165d442a5e3a54ee2e3b433f53b3613 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168120 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-14loplugin:ostr in svlNoel Grandin
Change-Id: Idae670a53d6d9aab0ec7132077f3e7b7f6fa5287 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167595 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-28reduce symbol visibilityNoel Grandin
Change-Id: Iad2d114d257244f456d5579636e5c25ce070a08a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166805 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-23ITEM: Add measurements for SfxItemSet usages (debug only)Armin Le Grand (allotropia)
I was wondering how much of that arrays of pointers to SfxPoolItems is actually used in the SfxItemSets in real office runtime, so I added code now to measure that. It does use the state of the ItemSet at destruction, so it is possible that items were added/removed which are not covered, but most cases of internal usages do not do that. I then check/sort the collected data at office shutdown, it will be printed as SAL_INFO when svl.items/vcl.items is set, so use this to see the data. This gives info about the average space utilization in different ItemSets with different sizes, also gives an insight about used ItemSet sizes and amount of their usages. Of course results differ from app to app and dependent of what is done with the office, but interestingly when using quite some files opening from all apps it toggles/normalizes to something around 20-25%... Change-Id: I3eb2f0401c39a5bdb5d1d8176e95df07be4c111a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166455 Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Jenkins
2024-04-20loplugin:constantparamNoel Grandin
Change-Id: I4963987a63d82dfe086932307675f92deebb8883 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166316 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-19loplugin:constantparamNoel Grandin
Change-Id: I58e31ffdfc87a15e82bce54afd47ff3906159707 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166293 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-18tdf#160706 speed up loading conditional formatting rule in XLS (II)Noel Grandin
Reduce the work we do in IndexedStyleSheets::Reindex takes my test document from 117s to 48s Change-Id: I2e23b05684d0f2e3a9dc05c0a0fc4e9bbea7008d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166180 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-12fold OnDemandNativeNumberWrapper ctor and init togetherCaolán McNamara
Change-Id: I79e2cb4c81a2bbac4da16ece778e4ad3acc59eb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166025 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-04-12crashtesting: assert seen on importing forum-mso-en4-62805.xlsxCaolán McNamara
Change-Id: I1d1ab4539775c8c2fce591ca32fc15c3c0dd6060 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166024 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-04-04loplugin:unusedmethodsNoel Grandin
Change-Id: I19f466a272c821185bea4b45efd34392e525c0d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165785 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-04fix 'tdf#158773 reduce dynamic_cast'ing in CustomShapeProperties::Notify'Noel Grandin
I messed up in commit 9c5fda14fff397d5d503f749ad019791d7e4ef83 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Wed Mar 6 16:20:41 2024 +0200 tdf#158773 reduce dynamic_cast'ing in CustomShapeProperties::Notify and forgot to actually use the new SfxHintId::StyleSheetModifiedExtended I created in the constructor of the SfxStyleSheetHint class Change-Id: Ica661a156d72c8a4b8ad415b6f45fe5d3458ba26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165787 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-03svx: read font and spacing scaling from oox, add bot as UNO prop.Tomaž Vajngerl
- Read spacing in oox. - Add spacing scaling as a property. - Rename property "TextFitToSizeScale" to "TextFitToSizeFontScale" - Add property "TextFitToSizeSpacingScale" Change-Id: Icde575e55a3146169d86bb538a57adcf1fa228a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165633 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-04-02crashtesting: SvNFEngine::DefaultCurrencyRO assertCaolán McNamara
seen with forum-mso-en4-207468.xls so we will have to ensure that nDefaultSystemCurrencyFormat is set before using the RO mode Change-Id: Ib1e755203917ddd751a1493c817cc8383bbbc043 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165658 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-29speed up ScPatternAttrNoel Grandin
we know that ScPatternAttr uses a single, contiguous range of item ids, so we can compute the item offset at compile time. Shaves 1-2% off some workloads. Change-Id: I623b8cb3e0d5d070118117196d2b48575f505725 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165550 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-29crashtesting: fix SvNFEngine::CacheFormatRO assertCaolán McNamara
since: commit c6c6126aa3e8de256091b829b98b5943db6a8be6 Author: Caolán McNamara <caolan.mcnamara@collabora.com> Date: Thu Mar 21 17:25:35 2024 +0000 Related: tdf#160056 refactor SvNumberFormatter to split it into two constituent parts Change-Id: I4add9f383789ab03ceab751b07973448a41911ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165490 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-27drop const_cast and be more honest that internal state changesCaolán McNamara
Change-Id: I20dd009b2bd14cdf958572dabc7a7e565a2f98ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165393 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-24fix CppunitTest_sc_subsequent_filters_test4 intermittent failureCaolán McNamara
Change-Id: Ieb532183fd07915f8e0f2ec0cc3983a390024522 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165257 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-22Related: tdf#160056 refactor SvNumberFormatterCaolán McNamara
to split it into two constituent parts SvNFFormatData which is the data store for number formats it generally operates on. SvNFLanguageData for data around the current language in use. and then a SvNFEngine which implements the interaction between those parts SvNFEngine has two policies, the typical RW mode and a new RO mode where the SvNFFormatData doesn't change, all formats needed in this mode must already exist. Change-Id: I56b070ccd2e556a0cb1fe609a2fae28e18277c8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165146 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-22improve loplugin:staticmethodsNoel Grandin
Some of the exclusions were too aggressive. Restrict them to only the important classes, which exposes some more places this plugin applies. Change-Id: I1b2d1fb24391adc71ed0984f94168f61a149479f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165154 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-03 08:47:03 +0000