aboutsummaryrefslogtreecommitdiff
path: root/source/dz
ModeNameSize
d---------accessibility39logplain
d---------avmedia39logplain
d---------basctl39logplain
d---------basic39logplain
d---------chart239logplain
d---------connectivity74logplain
d---------cui39logplain
d---------dbaccess39logplain
d---------desktop39logplain
d---------dictionaries2242logplain
d---------editeng39logplain
d---------extensions72logplain
d---------extras / source33logplain
d---------filter72logplain
d---------forms39logplain
d---------formula39logplain
d---------fpicker39logplain
d---------framework39logplain
d---------helpcontent2 / source33logplain
d---------instsetoo_native / inc_openoffice / windows41logplain
d---------librelogo / source33logplain
d---------nlpsolver61logplain
d---------officecfg / registry / data / org35logplain
d---------oox39logplain
d---------readlicense_oo35logplain
d---------reportbuilder / java / org / libreoffice / report / function31logplain
d---------reportdesign39logplain
d---------sc39logplain
d---------scaddins39logplain
d---------sccomp39logplain
d---------scp2 / source33logplain
d---------sd39logplain
d---------setup_native / source33logplain
d---------sfx284logplain
d---------shell72logplain
d---------starmath39logplain
d---------svl39logplain
d---------svtools39logplain
d---------svx39logplain
d---------sw39logplain
d---------swext / mediawiki36logplain
d---------sysui / desktop34logplain
d---------uui39logplain
d---------vcl39logplain
d---------wizards72logplain
d---------writerperfect39logplain
d---------xmlsecurity39logplain
generated by cgit (git 2.34.1) at 2025-01-15 11:10:28 +0000
hidpi-bits LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/include/svx/sdr/primitive2d/sdrframeborderprimitive2d.hxx
AgeCommit message (Collapse)Author
2024-02-12make BufferedDecompositionPrimitive2D store a Primitive2DReference..Noel Grandin
.. instead of a Primitive2DContainer. The container very frequently contains only a single item, since the decomposition method often sticks only a single top-level node in there, so it turns out to be a net loss overall, memory consumption-wise. Also, if we return a single Primitive2DReference from a BufferedDecomposition, that maximises the sharing of data between the BufferedDecomposition objects at the bottom of the decomposed tree, and objects higher up. Change-Id: Iaf272e60e2997299cc35a1bd209c51b6b79e9a8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162976 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-10-02tdf#146619 Recheck include/s* with IWYUGabor Kelemen
Change-Id: Ia0a6330278b044f448c9928362308aadc8fc9a20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156989 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-01-30tdf#150534 reduce allocation in SdrFrameBorderPrimitive2DNoel Grandin
Change-Id: Ib55ce7882e87823cca95e00cb5ae990213d1e766 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146339 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21drawinglayer: put BufferedDecompositionPrimitive2D in its own fileTomaž Vajngerl
And fix includes all over the place... Change-Id: I6e2696bbeeac6ab7467cac70545fa7209aa981a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117528 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
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>
2020-07-19compact namespace: svxNoel Grandin
Change-Id: I15c64c6cc0ae2a0f1fb9a3e1651dda1d6ced7585 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99008 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-06tdf#120216 improve svx table performance.Mark Hung
By defining operator== for SdrConnectStyleData and SdrFrameBorderData, and make a deeper comparison instead of the pointer stored shared_ptr in SdrFrameBorderPrimitive2D. The SdrFrameBorderPrimitive2D::operator== always return false before. The response time of clicking a cell and then entering editing mode improved from 4s to 0.5s in my environment. Change-Id: I625d9f69a07f42cac4a6cba45ec9e1c4195b6d58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90120 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-27loplugin:constantparamNoel Grandin
Change-Id: I62a0b760e49e38a4565eebf272492159047dda5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89613 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-07remove use of macro DeclPrimitive2DIDBlock in everywhereTomaž Vajngerl
Change-Id: I3fcba604ee3bc95274700ae7406f27e292cd09ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88154 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-02-02tdf#128302: Split SVXCORE_DLLPUBLIC from SVX_DLLPUBLICStephan Bergmann
Using SVX_DLLPUBLIC for both Library_svxcore and Library_svx had started to cause failures with clang-cl on Windows now, presumably due to devirtualization: > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::DataChanged(class DataChangedEvent const &)" (?DataChanged@SvxMetricField@@MEAAXAEBVDataChangedEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::PreNotify(class NotifyEvent &)" (?PreNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual bool __cdecl SvxMetricField::EventNotify(class NotifyEvent &)" (?EventNotify@SvxMetricField@@MEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "protected: virtual void __cdecl SvxMetricField::Modify(void)" (?Modify@SvxMetricField@@MEAAXXZ) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::PreNotify(class NotifyEvent &)" (?PreNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > linectrl.o : error LNK2001: unresolved external symbol "private: virtual bool __cdecl SvxFillAttrBox::EventNotify(class NotifyEvent &)" (?EventNotify@SvxFillAttrBox@@EEAA_NAEAVNotifyEvent@@@Z) > C:\lo-clang\core\instdir\program\svxcorelo.dll : fatal error LNK1120: 6 unresolved externals Replacing certain uses of SVX_DLLPUBLIC with the newly introduced SVXCORE_DLLPUBLIC (include/svx/svxdllapi.h) has been done on Linux as follows: > git grep -w --line-number -e SVX_DLLPUBLIC --and --not -e '#define SVX_DLLPUBLIC' >LINES to produce a file LINES containing all 640 uses. (Conveniently, all uses happen to be on different lines.) Manually create a file TOKENS with 640 corresponding lines, each containing the (class or function) name that is made SVX_DLLPUBLIC by in the corresponding line in LINES. Then > nm -D --def instdir/program/libsvxcorelo.so | grep -ivw '[vw]' | c++filt >SVXCORESYMS > nm -D --def instdir/program/libsvxlo.so | grep -ivw '[vw]' | c++filt >SVXSYMS > n=$(cat TOKENS | wc -l) > for ((i=1;i<="$n";++i)); do > tok=$(head -n "$i" TOKENS | tail -1) > printf @ > grep -Fw "$tok" SVXCORESYMS >/dev/null && printf svxcore > printf @ > grep -Fw "$tok" SVXSYMS >/dev/null && printf svx > printf '@ ' > head -n "$i" LINES | tail -1 > done to generate 640 output lines detailing for each SVX_DLLPUBLIC name occurrene whether it is mentioned in exports from neither (@@@), only from svx (@@svx@), only from svxcore (@svxcore@@), or from both libraries (@svxcore@svx@). The numbers that gives is 10 @@@ 180 @@svx@ 424 @svxcore@@ 26 @svxcore@svx@ The 10 @@@ ask for follow-up clean up, but most of them are just left as SVX_DLLPUBLIC for now. The exceptions are sxv::ITextProvider (include/svx/itextprovider.hxx) and SdrCustomShapeGeometryItem::PropertyPairHash (include/svx/sdasitm.hxx, where PropertyPairHash is a member struct of SVXCORE_DLLPUBLIC SdrCustomShapeGeometryItem). Keeping them as SVX_DLLPUBLIC would cause "unresolved externals" errors when linking Library_svxcore on Windows. The 180 @@svx@ are fine to keep as-is, and the 424 @svxcore@@ need rewriting. The 26 @svxcore@svx@ needed manual inspection to decide (in some cases, the chosen name in TOKENS was a too generic function name like Fill, in other cases it was the name of a class exported from one library but also mentioned in the arguments of a function exported from the other). And for sdr::table::SdrTableObj the class itself is defined in svxcore while the static member functions ExportAsRTF and ImportAsRTF are defined in svx. But MSVC does not allow to mark the class as SVXCORE_DLLPUBLIC and the two static member functions as SVX_DLLPLUBIC, so move the two functions out of the class. (There appears to be no real necessity that they were static member functions in the first place; they don't even need to be friends of the class. Nevertheless, this mixture of functionality from svxcore and svx in include/svx/svdotable.hxx may ask for follow-up clean up, one way or another.) All the output lines that need rewriting (all the @svxcore@@ ones, and the manually picked subset of @@@ and @svxcore@svx@ ones) are copied into a new file CHANGE (containing 451 lines). Then > sed -E -e 's|^@.*@.*@ ([^:]+):([0-9]+):.*$|sed -i -e "\2 s/SVX_DLLPUBLIC/SVXCORE_DLLPUBLIC/" \1|' <CHANGE >COMMANDS > . COMMANDS to do the changes. Change-Id: If9b6dd1c9e9ba2eb883dbdac4385d28c6fc8a203 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87794 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-30loplugin:finalclasses svxNoel Grandin
Change-Id: If55e51b8627083ba3ece2b3270adb47668b25e9d Reviewed-on: https://gerrit.libreoffice.org/81705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-25Reorganize FrameBorderPrimitive creation (II)Armin Le Grand
Step5: Move the view-dependent decomposition from BorderLinePrimitive2D to SdrFrameBorderPrimitive2D. It is now possible to use discrete sizes before the line and edge matching is done what will look much better. When it was done at BorderLinePrimitive2D and the matching was already done, that match was 'displaced' with the adapted forced scale to discrete units. The space and size used when zooming out for a single discrete unit (pixel) can heavily vary - it just covers a much larger logical area than the 'real' line/poly would do. All this needs to be handled (also for bound ranges) and can only be in a good way using primitives. Adapted to no longer do view-dependent changes in BorderLinePrimitive2D. Adapted to do these now at SdrFrameBorderPrimitive2D. Currently used to force the existing border partial lines (up to three) to not get taller than one logical unit. Adapted to no longer switch off AntiAliased rendering in VclPixelProcessor2D for processBorderLinePrimitive2D, this is problematic with various renderers on various systems (e.g. vcl still falls back to render multiple one-pixel-lines when taller than 3.5 pixels which looks horrible combined with other parts like filled polygons) All this needs fine balancing on - all systems - all renderers - all apps (which all have their own table implementation) - all render targets (pixel/PDF/print/slideshow/...) Done as thorough as possible, but may need additional finetuning. May also be a motivation to move away from vcl and implement these urgetly needed system-dependent primitive renderers... Adapted UnitTest testDoublePixelProcessing with the needed comments. Change-Id: Ie88bb76c2474b6ab3764d45a9cd1669264492acd Reviewed-on: https://gerrit.libreoffice.org/62344 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-10-24Removed executable permission on hxx fileAndrea Gelmini
Change-Id: I0004193fc0de93632cdd05628052c35cc524690f Reviewed-on: https://gerrit.libreoffice.org/62311 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-10-24Reorganize FrameBorderPrimitive creationArmin Le Grand
Step1: Basic concept, move stuff to svx and new SdrFrameBorderPrimitive2D Step2: Adapt all creators/usages to use SdrFrameBorderData/SdrFrameBorderPrimitive2D, check functionality Step3: Re-implement mergre of BorderLinePrimitive2D during decomposition of SdrFrameBorderPrimitive2D to keep the number of primitives low from the start, make merge optional (not urgently needed) Step4: Migrate and isolate all helper methods and classes involved in geometry creation of border lines to the implementation (.cxx) of the new primitive Change-Id: I840b6765439bd995f2c57ef36315427b1f0f3e21 Reviewed-on: https://gerrit.libreoffice.org/62247 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>