/vcl/workben/

aoo/trunk LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sw/source/core/text/txtcache.cxx
AgeCommit message (Collapse)Author
2021-04-09Recheck include/ with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: Ifc253bf800bb1468b5774663a93f4fb30bec81d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113657 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-08sw: prefix members of SwArrowPortion, SwTextLine, SwTextPainter and ...Miklos Vajna
... WidowsAndOrphans See tdf#94879 for motivation. Change-Id: I1999c83e5afe100b95481ac470f4d854b5f113f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110547 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-09tdf#128502: Try to support multiple documents in LibreOfficeKit-using processTor Lillqvist
The LibreOfficeKit-specific code typically has assumed that all the "views" (SfxViewShell instances) are for the same document, because all LibreOfficeKit-based application processes (including the "kit" processes in Online and the iOS app) so far have only had one document open at a time. It is now possible to pass several document file names on the command line to gtktiledviewer and that is an easy way to demonstrate how badly it still works even with this patch. Introduce a unique numeric document id that is increased in the LibLODocument_Impl constructor. Add APIs to access that. When iterating over views, try to skip views that are not of the document visible in the "current" view, if we know what the "current" view is. Also add a couple of FIXMEs at places where it is a bit unclear (to me) whether it is correct to iterate over all views, or whether only views for the "current" document are what we would want. Change-Id: Id5ebb92a115723cdeb23907163d5b5f282016252 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95353 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-05-28tdf#125475 sw: update SwTextFrames when SwTextLine cache shrinksMichael Stahl
SwCache::DeleteObj() may decide to shrink the cache, and then the SwTextFrame::mnCacheIndex goes stale, because only SwCacheObj::m_nCachePos is updated. In this bugdoc, this can happen *inside* SwTextFrame::Format(), where first it succeeds to find an existing SwTextLine, then some footnotes anchored in this paragraph are moved around and formatted, creating new SwTextLines, and SwCache::DeleteObj is called. Later, any access of the original frame's SwTextLine fails to find it and eventually some null pointer crash happens. Newly added SwTextLine::UpdateCachePos() requires that SwTextFrame lives longer than its SwTextLine; there was another problem with that, because SwTextFrame::FormatEmpty() was throwing away the mnCacheIndex, which could then cause a second SwTextLine to be created for the same SwTextFrame, and the first one is not deleted until it falls to the bottom of the LRU list. Apprently for this particular document the problem didn't happen before commit 3d37463eec0c891243a8971a34903b2da01c9e24 and/or commit 31ae7509003b1e650463ee1468c0b315ba13efe6 but that is mostly luck. Change-Id: I7bef1b340a453d6dd44d51a1dc69ee5fd0b697db Reviewed-on: https://gerrit.libreoffice.org/73047 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-04-30tdf#122607 sw: fix preservation of text frame cache entriesMichael Stahl
SwSaveSetLRUOfst would leave only 50 cache entries available for the CalcLayout() to use; apparently it's not enough for this document. The difference between the 1st loading/layout and the 3rd loading/layout of the document is that in many paragraphs the cache entry is missing, because the entires of the previous loads were clogging up the cache and were preserved here, and the cache only has 50 available entries; if enough entries are available, everything is positioned properly. The idea with the 100 entries per visible shell actually comes from the CVS initial import, where there was a comment suggesting that; but the corresponding parameter was actually unused and removed in 7c704c78d3c652504c064b4ac7af55a2c1ee49bb. Ideally we'd have time to investigate why a missing cache entry causes the wrong position... Change-Id: I64a72a94361dbf5717bbc709fa3bc9abbe18a37c Reviewed-on: https://gerrit.libreoffice.org/71542 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2018-08-22loplugin:useuniqueptr in SwTextLineNoel Grandin
Change-Id: I3c3cdf14d8d86028c452e190dea5fa1bb3da0cbb Reviewed-on: https://gerrit.libreoffice.org/59443 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-23loplugin:includeform: swStephan Bergmann
Change-Id: Ifc3c4c31a31ee7189eeab6f1af30b94d64f2f92a
2017-08-04loplugin:constparams in sw part4Noel Grandin
Change-Id: Ic42b2691869b61ba906222db893e284d8b9c39c1 Reviewed-on: https://gerrit.libreoffice.org/40767 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-01-13new loplugin: useuniqueptr: sw part 1Noel Grandin
Change-Id: I2bc55634e80976951ede768c97fbc4b7c4eda46c Reviewed-on: https://gerrit.libreoffice.org/32963 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>