summaryrefslogtreecommitdiff
path: root/vcl/opengl/FixedTextureAtlas.cxx
AgeCommit message (Collapse)Author
2016-11-07opengl: use shared_ptr for ImplOpenGLTextureTomaž Vajngerl
Change-Id: I755e312e3e0a69b99a8f02f7d05561b7289845ce Reviewed-on: https://gerrit.libreoffice.org/30597 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2016-08-18cppcheck: noCopyConstructorCaolán McNamara
Change-Id: Id5323cb6f52666f85965e11b07e4f2bca8af4e78
2016-06-08tdf#100184 fix the lifecycle of a texture in an atlasTomaž Vajngerl
Previously, when a texture atlas was destroyed we teared down the ImplOpenGLTexture even if there were OpenGLTexture instances around. This caused that we could try to access an already deallocated ImplOpenGLTexture which causes a seg. fault. Now we change this so that a FixedTexture is no different than a OpenGLTexture - we just release the reference, so any existing OpenGLTextures for our texture would still be valid. An additional problem is that FixedTexture registers a callback for slot deallocation so we know when a OpenGLTextures that holds a specific "slot" on the texture is deallocated. However if FixedTexture is not existent anymore, the callback still gets triggered and is trying to access invalid memory. To solve this we need to unregister callbacks before FixedTexture is destroyed. Additionally improve validity of a OpenGLTexture is valid. If ImplOpenGLTexture is not allocated (nullptr) is one case, but in addition to that if ImplOpenGLTexture has an id == 0 it also means that it is not valid (anymore). Change-Id: I87346198e8928e112619da62687d5856cb8aafb8
2016-05-30tdf#94205 Use o3tl::make_unique instead of new + std::movekrishna keshav
removed std::unique_ptr and std::move to make_unique in vcl/opengl/FixedTextureAtlas.cxx Change-Id: I7cbff152c3daae68a18ec08607cac030a1f4af8e Reviewed-on: https://gerrit.libreoffice.org/25613 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-04-08opengl: refactor GL texture slot mechanism to be more generalTomaž Vajngerl
Slot mechanism in ImplOpenGLTexture was written to support needs for FixedTextureAtlas. This commit makes the slot mechanism more general so it can be used in other kinds of texture atlases like PackedTextureAtlas. The ImplOpenGLTexture still tracks slots, but it is not needed to define beforehand how many slots there are. The deallocation has been factored out, ImplOpenGLTexture instead calls a callback function that a slot with a specific "slot id" has been deallocated. Change-Id: I23950d325b803969f958d03ebf34805687c4e620
2016-04-08opengl: texture atlas impl. to efficiently packs texturesTomaž Vajngerl
Change-Id: I66b3eddadb172da26aa1a62f2a795895769db93b
2016-01-06vcl: fix lifecycle errors & memory corruption.Michael Meeks
FixedTextureAtlasManager should use ref-counted textures properly. Also - dispose embedded textures early in VCL shutdown while we have a valid OpenGLContext. Also - dispose the native widget control cache earlier too. Change-Id: Id3f7a1c3b331496616f36cbf02f83737505278a5 Reviewed-on: https://gerrit.libreoffice.org/21148 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2015-09-16opengl: optimize search for a free slot in texture atlasTomaž Vajngerl
Change-Id: Ic853457871b914f9c1beb2f648bf7d9d18dce957
2015-08-24-Werror,-Wpessimizing-move ("moving a temporary object prevents copy elision")Stephan Bergmann
Change-Id: I9e5b74e5ff0348f0880972a82726178354ab7d0f
2015-08-24Fixed (fixed size) texture atlas for "caching" OpenGL texuresTomaž Vajngerl
Change-Id: I7fe90c0a0033b4d9a341a4f0b8356d7f7133e93e
generated by cgit (git 2.34.1) at 2025-01-15 13:49:56 +0000
were referenced. This *required* to have only one incarnation per item to have a minimal binary file size, thus this high effort was put into this. At doc load, the pool was loaded, all Items were set to RefCount 5000, the references from the objects were restored and then for each Item the RefCount was lowered by 5000 again and - if being zero - deleted. Items for UI were marked 'non-poolable' to *not* safe them with the document, so poolable was a flag to decide if that Info/Item was to be saved with the document - or more direct: if it is Model Data. Items are small, so if we prefer runtime it is okay to no longer being strict with this, anyways does not happen often and has only marginal memory effects - compared to runtime effects/savings. Other problems which this caused: One example is that objects in the UNDO stack were still in the pool, so e.g. deleted pictures were saved with the document despite no longer being used (!). That is the reason we have an UndoItemPool and a method MigrateItemPool to move stuff to that Pool when objects go to the UNDO stack - all of this is also no longer needed. Cleaning this up means to ideally have all items in the SfxItemSet, no longer at the Pool. The Pool should be reduced to a 'Default-Item- Holder' and a 'Slot-to-whichId-mapper'. This needs thorough cleanups/removals, but will be worth it because that massive simplification(s) will increase safety an runtime and make migrating to the goal of completely type-based ItemSet stuff easier for the future. Hopefully only view code in the office working with items will have to be changed for this. In this 1st step I already found that some 'compromizes' will be needed: - There are still Items that have to be at the pool to make the Surrogate-stuff working. This gives back all Items in a Pool of a type and is used in ca. 80 cases. Each one looks at these Items *without* context (e.g. a SfxItemSet at an Object would be a context), so if e.g. a dialog is open that temporarily uses Items of that type you would also get these - without knowing about it... To make that work there is still a mechanism to have Items at the Pool, but now just *registering* (and un-reg) them without any sort/search/ remove needs. Also only for Items that need that, so I evaluated the GetItemSurrogates calls and added some asserts when GetItemSurrogates tries to access an unregistered item type which needs to be added. - Another caveat is that there are about 250 places that directly put Items to the Pool (not all remove these, that is done at pool deletion, so some kind of silent 'garbage-collection' is in place). To have an overview I renamed the accessing methods to separate them from the same functionality at the SfxItemSet, which had the same names. An implementation does still add these directly to the pool, there is no way to cleanup those usages for now. In principle all these should be changed to hold the data at an SfxItemSet. I am still hunting problems. But you can build the office, all apps work (including chart) and you can do speed comparisons already. There are test throwing errors, so I hunt these now. It is hard to give an estimation about how much more changes/corrections will be needed. Completed adaptions to new registered Items at Pool, that reduces the failing tests. Still many that I need to hunt. Added stuff to work around that 'compromize' in ScDocumentPool: It overloads ::PutImpl of the pool to implement special handling for a single Item in SC, the ScPatternAttr. In former code that method was used from SfxItemSet and ::PutImpl at the pool directly, so it was only used in one place. I am not sure if it was used from the SfxItemSet functionality, but better offer it for now. To not waste too much runtime the callbacks depend on the boolean 'NewItemCallback' at the SfxPoolItem, it gets set for that single Item in SC and only then the callbacks trigger. I hope to get rid of those again, e.g. newItem_UseDirect is only needed since we have no 'real' StaticPoolDefaults currently - another thing that needs to be cleaned up in a next step. Since usages of impl(Create|Cleanup)ItemEntry and Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it globally available in svl and use it also directly for Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that fallback (e.g. tryToGetEqualItem) was used before, thus this is the same class of errors (SfxPoolItem ptr-compare) as the others which I will need to find anyways. Also fixed some missing stuff. Have now idenified and redirected all SfxPoolItem ptr-compares to be able to debug these - one cause for the remaining errors is probably that before with bPoolable those often were sufficient, but are no longer. Used the [loplugin:itemcompare] and a local clang build to do so, see https://gerrit.libreoffice.org/c/core/+/157172 Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter to implCreateItemEntry to signal that it gets called from DirectPool stuff - currently needed. Hopefully when getting rid of that DirectPool stuff we can remove that again Added two more debug functionalities: - Added a SerialNumber to allow targeted debugging for deterministic cases - Added registering & listing of still-allocated SfxPoolItems at office shutdown Found PtrComp error in thints.cxx - POC, thanks to areSfxPoolItemPtrsEqual. Will hopefully help more with other tests Found some wrong asserts/warnings where I was too careful and not finding something/succeeding is OK, fixes some UnitTests for SC For SC I now just tried to replace all areSfxPoolItemPtrsEqual with the full-ptr-content compare SfxPoolItem::areSame. I also needed to experiment/adapt the newItem_Callback solution but got it working. Did that replacement now for SW too, found some places where the direct ptr compare is OK. Continued for the rest of occurrences, now all 160 places evaluated. Also done some cleanups. Massive cleanups of stuff no longer needed with this paradigm change. Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now. It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that already needs many exceptions. Also useful for testing if errors come up on this change to test if it is related to this. Added forwarding of target Pool for ::Clone in SvxSetItem and SvxSetItem, simplified SfxStateCache::SetState_Impl and returned to simple ptr compares in SfxPoolItem::areSame to not do the test in areSfxPoolItemPtrsEqual. Debugged through UITest_calc_tests9 and found that in tdf133629 where BoxStyle is applied to fully selected empty calc the Item- reuse fallback has to be used not only for ATTR_PATTERN, see comment @implCreateItemEntry. Maybe more... Problem with test_tdf156611_insert_hyperlink_like_excel. Found that in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField is found and returned as ptr, but it's usage crashes. That is due to the SfxItemSet aEditSet used there gets destroyed at function return what again deletes the SvxFieldItem that is holding the SvxURLField that gets returned. This shows a more general problem: There is no 'SfxPoolItemHolder' that safely holds a single SfxPoolItem - like a SfxItemSet for a single Item (if Items would be shared_ptrs, that would be a safe return value). That will be needed in the future, but for now use another solution: Since I see no reason why EE_FEATURE_FIELD should not be shareable I wil change this for ow in the SfxItemInfo for EditCharAttribField. That way the Item returned will be shared (RefCnt > 1) and thus not be deleted. I changed the return value for GetURLField() and GetFirstURLFieldFromCell() in ScEditShell: At least for GetFirstURLFieldFromCell the return type/value was not safe: The SvxFieldItem accessed there and held in the local temporary SfxItemSet may be deleted with it, so return value can be corrupted/deleted. To avoid that, return a Clone of SvxFieldData as a unique_ptr. With all that UnitTest debugging and hunting and to get the paradigm change working to no longer rely on shared/pooled items I lost a little bit focus on speed, so I made an optimization round for the two central methods implCreateItemEntry/implCleanupItemEntry to get back to the speed improvements that I detected when starting this change. It was mainly lost due to that 'strange' chained pool stuff we have, so I added to detect the target pool (the one at which the WhichID is registered) directly and only once. Next thing to cleanup will/should be the pool and it's concept, all this is not needed and really costs runtime. Since implCreateItemEntry/implCleanupItemEntry are executed millions of times, each cycle counts here. Had an error in the last changes: pool::*_Impl methods use index instead of WhichID - most of them. Another bad trap, I really need to cleanup pool stuff next. Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2023-04-28Revert "Revert "introduce sw::SpzFrameFormat ...""Bjoern Michaelsen apparently, in SwHistoryChangeFlyAnchor::SetInDoc, m_rFormat might actually reference a DrawFormat, not a FlyFormat, and that is likely fundamentally broken. But for now, lets just make m_rFormat a sw::SpzFrameFormat -- this already removes some pointless up and downcasting. This reverts commit 52acefd6024ec79f8333ba40eef83816eda3046f. Change-Id: I040d98548bf9ac1c25b93214224eb0812f8cb653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151150 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> 2023-04-27Revert "introduce sw::SpzFrameFormat ..."Stephan Bergmann This reverts commit 09cdcb5f37bb4e42da7b28db6e757b9f2affed14. It broke at least CppunitTest_sw_uiwriter3 (<https://ci.libreoffice.org//job/lo_ubsan/2756/>), > /sw/source/core/undo/rolbck.cxx:938:46: runtime error: downcast of address 0x61300041fd00 which does not point to an object of type 'SwFlyFrameFormat' > 0x61300041fd00: note: object is of type 'SwDrawFrameFormat' > 00 00 00 00 70 83 cf 09 25 7f 00 00 00 83 47 00 30 61 00 00 40 e5 43 00 30 61 00 00 80 66 5d 00 > ^~~~~~~~~~~~~~~~~~~~~~~ > vptr for 'SwDrawFrameFormat' > #0 0x7f24fca9c5b9 in SwHistoryChangeFlyAnchor::SetInDoc(SwDoc*, bool) /sw/source/core/undo/rolbck.cxx:938:46 > #1 0x7f24fca880f3 in SwHistory::Rollback(SwDoc*, unsigned short) /sw/source/core/undo/rolbck.cxx:1208:15 > #2 0x7f24fcb47832 in SwUndoDelete::UndoImpl(sw::UndoRedoContext&) /sw/source/core/undo/undel.cxx:1031:33 > #3 0x7f24fcb703c2 in SwUndo::UndoWithContext(SfxUndoContext&) /sw/source/core/undo/undobj.cxx:225:5 > #4 0x7f2543b8b57c in SfxUndoManager::ImplUndo(SfxUndoContext*) /svl/source/undo/undo.cxx:712:22 > #5 0x7f2543b8c4f8 in SfxUndoManager::UndoWithContext(SfxUndoContext&) /svl/source/undo/undo.cxx:664:12 > #6 0x7f24fca6a074 in sw::UndoManager::impl_DoUndoRedo(sw::UndoManager::UndoOrRedoType, unsigned long) /sw/source/core/undo/docundo.cxx:696:32 > #7 0x7f24fca6b38f in sw::UndoManager::UndoWithOffset(unsigned long) /sw/source/core/undo/docundo.cxx:731:16 > #8 0x7f24fa830b18 in SwEditShell::Undo(unsigned short, unsigned short) /sw/source/core/edit/edundo.cxx:141:57 > #9 0x7f250088f448 in SwWrtShell::Do(SwWrtShell::DoType, unsigned short, unsigned short) /sw/source/uibase/wrtsh/wrtundo.cxx:45:26 > #10 0x7f24ff7f16e2 in SwBaseShell::ExecUndo(SfxRequest&) /sw/source/uibase/shells/basesh.cxx:651:27 > #11 0x7f24ff7eea14 in SfxStubSwBaseShellExecUndo(SfxShell*, SfxRequest&) /workdir/SdiTarget/sw/sdi/swslots.hxx:2203:1 > #12 0x7f2523fbc059 in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) /sfx2/source/control/dispatch.cxx:254:9 > #13 0x7f2523fd1ced in SfxDispatcher::Execute_(SfxShell&, SfxSlot const&, SfxRequest&, SfxCallMode) /sfx2/source/control/dispatch.cxx:753:9 > #14 0x7f2523f61333 in SfxBindings::Execute_Impl(SfxRequest&, SfxSlot const*, SfxShell*) /sfx2/source/control/bindings.cxx:1060:22 > #15 0x7f252437496b in SfxDispatchController_Impl::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) /sfx2/source/control/unoctitm.cxx:688:53 > #16 0x7f2524377211 in SfxOfficeDispatch::dispatchWithNotification(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) /sfx2/source/control/unoctitm.cxx:266:16 > #17 0x7f24cad28dd6 in framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatch> const&, com::sun::star::util::URL const&, bool, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/dispatchhelper.cxx:163:30 > #18 0x7f24cad27cb2 in framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/dispatchhelper.cxx:120:16 > #19 0x7f24cad29684 in non-virtual thunk to framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /framework/source/services/dispatchhelper.cxx > #20 0x7f24e91d386d in unotest::MacrosTest::dispatchCommand(com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) /unotest/source/cpp/macros_test.cxx:94:33 > #21 0x7f25319b2012 in testTdf132321::TestBody() /sw/qa/extras/uiwriter/uiwriter3.cxx:982:5 Change-Id: Ibeb181bc38cd6f88df76403cca8a15b45090633f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151027 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2023-04-24introduce sw::SpzFrameFormat ...Bjoern Michaelsen - ... as a base class of frame formats allowed into the spz frame format container - with a private ctor and friends SwDrawFrameFormat and SwFlyFrameFormat so only these two classes derive from it - with that, switch over the SpzFrameFormats to only ever allow these types into the container - in followups, likely quite a bit of stronger typing can be introduced. - ultimately, it would be nice to have each SwDrawFrameFormats and SwFlyFrameFormats in their own strongly typed container in the end. Change-Id: Ic30efc1220aded701533c9ca5003d2aaf8bbdaec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150452 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> 2021-05-29no need to allocate these on the heapNoel Grandin Change-Id: Ie4077a86523d623e1913c4f97971ab81d04abd4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116368 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-03-09Drop "32" from names of SbxArray methods taking 32-bit indicesMike Kaganski ... a leftover from times when there were methods for 16-bit as well as for 32-bit indices. 16-bit indices were removed in commit 62f3f3d92aa204eaaa063b30d7ade44df501b997. Change-Id: Idf8b1160e68e8b303cf75ea79dd7dbb3bd00275d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112187 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2020-11-24tdf#42949 Fix new IWYU warnings in directory swGabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I4bb84c3f401aba8a3dede9cec3a7f2187a2ba02a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106473 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>