summaryrefslogtreecommitdiff
path: root/vcl/headless/svpgdi.cxx
AgeCommit message (Collapse)Author
2019-08-14tdf#124700 don't pull from or insert into cache for PixelSnapHairlineCaolán McNamara
Change-Id: I7ca0f556164b6bc462cee3c5532733dbd6b68a2b Reviewed-on: https://gerrit.libreoffice.org/77455 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-09Related: tdf#122358 consistent transformation of damageCaolán McNamara
try to consistently transform our damaged regions. Quite possibly on the wrong track there, in which case just reverting to taking a cowardly grow(1) will probably suffice Change-Id: I251aec54e9df6c0f229f0c246332a1624a8b68d8 Reviewed-on: https://gerrit.libreoffice.org/77210 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-09Resolves: tdf#122358 ensure right/bottom borders are included in damage regionCaolán McNamara
a simple safely backportable expand of damage region by one pixel Change-Id: If4d226d8546d55b00172d826c8816b09b55d54ef Reviewed-on: https://gerrit.libreoffice.org/77206 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-24Related: tdf#126227 follow the same pattern as drawPolyPolygonCaolán McNamara
in drawAlphaRect so the rect path is set after the matrix Change-Id: I3ded9383f6f16f77902c5ad576e520f37326e8af Reviewed-on: https://gerrit.libreoffice.org/76199 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-24Resolves: tdf#126227 calc red change tracking rectangles missing their topCaolán McNamara
cairo_set_matrix doesn't appear to have any effect on an existing path, so set a new path on both fill and stroke so the matrix set for line will have an effect, so drop cairo_fill_preserve to cairo_fill and rely on the path cache. Change-Id: I31f16b094c920b107467a9492c7194bb578c1924 Reviewed-on: https://gerrit.libreoffice.org/76198 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-24Related: tdf#126227 factor out setting the polygon pathCaolán McNamara
this change should have no visual effect Change-Id: Id93519e6b74e2c9bc4ddf20e7ab903689d7d8ee3 Reviewed-on: https://gerrit.libreoffice.org/76197 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-24Related: tdf#126227 don't need preserve variant hereCaolán McNamara
we're calling cairo_fill_preserve so we can reuse the same path to stroke. We don't use this path again after stroke. this change should have no visual effect Change-Id: I1ad6af875b0a58a0699b5d9801c76510cc242ab9 Reviewed-on: https://gerrit.libreoffice.org/76196 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-09tdf#121793 use cairo_path_extentsNoel Grandin
instead of cairo_fill_extents, which is fairly expensive for drawPolyPolygon fill operations. Shaves about 10% off the CPU time for this bug Change-Id: I04d04eed1bb204f51537f0856844b337c5a4d54c Reviewed-on: https://gerrit.libreoffice.org/75287 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-18VCL cleanup WidgetDrawInterfaceJan-Marek Glogowski
I don't understand why WidgetDrawInterface, which is basically a copy of the SalGraphics native controls interface, duplicated it, instead of cleaning things up. The whole commit message of commit 8fcfa3853a81, which added this code, is just: "custom widgets: Custom Widget Themes". That's it. So this patch does, what the original one skipped: replacing the SalGraphics interface with the WidgetDrawInterface. One result is the addition of handleDamage to SalGraphics to correctly handle the damage done by a custom widget theme to the underlying SalGraphics implementation. Change-Id: I5fda1a64b28e6560fb3c62e02b6dcda827f698e2 Reviewed-on: https://gerrit.libreoffice.org/74118 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-15Attempt to load the theme when LibreOfficeKit is active.Jan Holesovsky
Change-Id: Ie8640b7179a96cb40fb774ede097ca7b3640edd8 Reviewed-on: https://gerrit.libreoffice.org/72349 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 7d55c2b8886ae00a60aa469503f596ee488c25c0) Reviewed-on: https://gerrit.libreoffice.org/72353 Tested-by: Jenkins
2019-05-03tdf#120585: use applyColor and make it transparency-awareKatarina Behrens
An overloaded drawPolyPolygon for zero transparency case used to exist and it used applyColor to fill cairo path. It was removed by commit 7034311dce663c895577267110baadbec312d491 and the new transparency-aware drawPolyPolygon missed cairo_set_operator call that is present in applyColor. This works OK most of the time but breaks sometimes when no transparency (~no antialiasing) is involved. To fix that add transparency argument to applyColor and use it where applicable Change-Id: Ib1b077e38e7f5d30778434d45be67284407a7d16 Reviewed-on: https://gerrit.libreoffice.org/71700 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-27remove comment in light of fix for tdf#120797Caolán McNamara
Change-Id: I3093f764a26abdbdb651596352ba74b7fa1c3306 Reviewed-on: https://gerrit.libreoffice.org/71399 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-26tdf#120797: Apply transformation also to the extents of damageKatarina Behrens
since 7034311dce663c895577267110baadbec312d491 affine transformation is passed down to drawPolyPolygon and drawPolyLine functions. The transformation was correctly applied to cairo context, but not the extents of damage so those had old, untransformed coordinates and were therefore not redrawn Change-Id: I61ce005ef8770ce5c4560a9d953cd92f440043be Reviewed-on: https://gerrit.libreoffice.org/71383 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-04Revert "raise cairo baseline to 1.12.0"Caolán McNamara
This reverts commit 50580f452cc7c88a231831619a3f05958ce56460. Revert "raise cairo baseline to 1.10.0" This reverts commit 58a0e60dee0d27a699f856827c20b792417d3478. 32bit baseline is currently at cairo 1.8.8 Change-Id: I5156df6aee03dbbb2e209dbd5717a98580256170 Reviewed-on: https://gerrit.libreoffice.org/70260 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-04raise cairo baseline to 1.12.0Caolán McNamara
Change-Id: I1816f23fea88e6b840539a88504956b00a546522 Reviewed-on: https://gerrit.libreoffice.org/70243 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-04raise cairo baseline to 1.10.0Caolán McNamara
Change-Id: I721b80d7ce28d36babbd2bd1957fcbd6a2d27a27 Reviewed-on: https://gerrit.libreoffice.org/70242 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-04Resolves: tdf#124219 check at runtime for availability of cairo functionsCaolán McNamara
Change-Id: I0ab3055760d8be690bdfff560212db368a0fa261 Reviewed-on: https://gerrit.libreoffice.org/70240 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-04-03Support for native 32bit Bitmap in VCL and SVP (cairo) backendTomaž Vajngerl
This adds basic support for 32bit bitmaps for the SVP backend. For other backends the support is disabled for now as we need to add it for each backend separately and enable support. When this patch is applied it is possible to a Bitmap with bit count 32, but currently no input filter uses this with the exception of the new PngImageReader(libpng based), which is used only for the icons. For a general support more things need to be implemented and tested: - conversion back and fourth between 32-bit and 24-bit + 8bit alpha (or other supported pairs) - 'raw' export of the bitmap needs to be handeled properly (like in SVM import/export) so it creates the correct image. - input filters need to be checked and converted if this is necessary - look for possible bugs when drawing transparent bitmaps - check of UNO API Change-Id: I7a7be0e6134dfdd9a7aeaef897131bb6e710ae7e Reviewed-on: https://gerrit.libreoffice.org/69289 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
2019-03-08make it possible to use FileDefinitionWidgetDraw in more backendsTomaž Vajngerl
Change-Id: I8871eb49e11d8c72c469230967c3c979091a0f9b Reviewed-on: https://gerrit.libreoffice.org/68898 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-03-04WidgetDrawInterface impl. to draw widgets from file definitionsTomaž Vajngerl
This adds FileDefinitionWidgetDraw which extends the WidgetDrawInterface and is responsible to draw the widgets from the definition gathered from an external file. The file must be (currently) in the user folder named definition.xml. It instantiates the WidgetDefinitionReader to get the definitions and sets the style colors when updateSettings is called. Later more definitions will be implemented. Change-Id: Id02111e8aed4648e5a306b0f5dbc9a02c9b2fcb0 Reviewed-on: https://gerrit.libreoffice.org/68645 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-02-26sal_uLong->sal_uInt32 in drawEPSNoel Grandin
Change-Id: I58beedfee1a55df971e778ba2aa3b6989ba53663 Reviewed-on: https://gerrit.libreoffice.org/68341 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-06missing cairo_surface_destroyCaolán McNamara
Change-Id: I4ff8dcf928ebefed1eaeebdcdcfb90c56ddfd39e Reviewed-on: https://gerrit.libreoffice.org/67440 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-01-29drop now hopeless non-optimal depth warningCaolán McNamara
pointless since... commit 33761c69e9d3fa16e7a5b176200d183dc3236627 Date: Sun Dec 3 23:35:26 2017 -0500 vcl-svp: Store 24-bit images in 3-byte pixels squashed the effort to percolate preferred target format as bitmap storage format Change-Id: I8a5367d4d7d251d5dd37011d0e51ab09cf5c57ac Reviewed-on: https://gerrit.libreoffice.org/67055 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-01-23loplugin:constparams in vclNoel Grandin
Change-Id: Icf1a952fbe190fd6c4efd89364136aa2b48050e3 Reviewed-on: https://gerrit.libreoffice.org/66767 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-10tdf#42949 Fix IWYU warnings in include/vcl/s*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ie87d27dd2c385a63349e0b322fd067ba03d2d152 Reviewed-on: https://gerrit.libreoffice.org/64479 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-12-05Revert "Compute (un-)premultiply_table at compile time"Stephan Bergmann
This reverts commit 644188bf7f3a07222f2b58a3794348197fb8ad24. It has been found to cause compilation failure ("vcl/source/bitmap/BitmapTools.cxx(1078): error C2131: expression did not evaluate to a constant") with Visual Studio 2017 version 15.9, as discussed in the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2018-December/081500.html> "Windows build failure - C2131: expression did not evaluate to a constant" (and Mike thankfully filed a bug upstream, <https://developercommunity.visualstudio.com/content/problem/398218/ c2131-error-with-stdarray-and-stdmake-integer-sequ.html>). Also, Jenkins node tb39 which runs the "Gerrit Windows" sub-job of Jenkins' "Gerrit for master" job apparently has such a Visual Studio 2017 version 15.9 installed, so keeps failing that job. Change-Id: I87d25863f2e07474fbb2df3c8f72cd2bcc89582e Reviewed-on: https://gerrit.libreoffice.org/64618 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-05tdf#121719: Revert fix for tdf#96971Xisco Fauli
it's still used on Mac. Revert it until XOL is removed This reverts 258301879bcd20397c38bbd522dea2c923bd9fc2 Change-Id: I06548a590f370618ad640724a1b9c59a3faceec2 Reviewed-on: https://gerrit.libreoffice.org/64582 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-03Compute (un-)premultiply_table at compile timeStephan Bergmann
Change-Id: I34e624fcd5d11d02c26e775f5acdddec1fca9d87 Reviewed-on: https://gerrit.libreoffice.org/64428 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-02use same [un]premultiplyCaolán McNamara
Change-Id: Idd1ca1243b64a9ec606382a0895e11376a2ec186 Reviewed-on: https://gerrit.libreoffice.org/64406 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-12-01Related: tdf#121721 use premultiply unpremultiply tablesCaolán McNamara
for tdf#121721 this brings the time down between pressing F5 and seeing the image from 4 seconds to 1.4 seconds Change-Id: I8e7f15e5126218b040e96f9143827ff788b4fb51 Reviewed-on: https://gerrit.libreoffice.org/64111 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-09custom widgets: Use only with LibreOfficeKit.Jan Holesovsky
Change-Id: I9f8f25ee72e93fdf575312b6b0c5d32be9ea45cc
2018-11-09LOK: custom widgets: reduce theme plugin API surfaceAshod Nakashian
Change-Id: I89dcf5a102be19fd1bc314a89538a121522f4a43
2018-11-09custom widgets: setup style setting in the widget libraryTomaž Vajngerl
Some theme colors are set using the style settings, which are implemented by each backend to correspond to the system theme. For custom widgets these need to also be set by the library itself. This commit adds the ground work and sets some of the colors for windows backgrounds. Change-Id: Ia65b1605b2b7bef7f01ff1feff2e7470479e626a
2018-11-09Support drawing custom widgets in headless backendTomaž Vajngerl
..and fallback the headless dawing also in gtk3 where needed Change-Id: Ic5da8fa7a04089342db8e2f334ced69691a15217
2018-11-08Bin some leftover and actually unnecessary iOS crack in vclTor Lillqvist
We don't need the '#define SvpSalGraphics AquaSalGraphics' in vcl/inc/headless/svpgdi.hxx. The actual AquaSalGraphics we use for iOS is in vcl/inc/quartz/salgdi.h. I don't remember the details of the convoluted history behind this. Change-Id: Ie56c3c93acf7ad89e10a05e75aa4ca7fd596ba98 Reviewed-on: https://gerrit.libreoffice.org/63098 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-11-01clang-tidy: (WIP) bugprone-too-small-loop-variable findingsTamás Zolnai
Change-Id: Iaa255b39928ac45dec1ed37e368c149d6027f561 Reviewed-on: https://gerrit.libreoffice.org/62701 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2018-10-06Support estimateUsageInBytes for SystemDependentDataArmin Le Grand
Change-Id: I6074035ed8f90e452915e9ecffdbe9363375e126 Reviewed-on: https://gerrit.libreoffice.org/61306 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-10-06Add GlyphCache instance to GenericUnixSalDataJan-Marek Glogowski
This gets rid of some statics and drops some duplicate code: - the X11 based GlyphCache => gone - the svp version of the GlyphCache => gone - the "normal" GlyphCache - the PrintFontManager And while at it move the implementation into its own file gendata.cxx. Change-Id: I9063139c9482f5f37285505f389cf5f32c02426b Reviewed-on: https://gerrit.libreoffice.org/61454 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-09-21Support buffering SystemDependent GraphicDataArmin Le Grand
Started to make the buffering more flexible by adding virtual methods virtual sal_uInt32 getHoldCyclesInSeconds() const; virtual sal_Int64 estimateUsageInBytes() const; to class SystemDependentData. This will allow to add more sensitive buffering/caching. Also fine-tuned Linux-derived classes actively used for buffering to be more sensitive when and where to reuse the buffered data Change-Id: Ifc69c318ade0209aff071d76001869d9f4eeb10d Reviewed-on: https://gerrit.libreoffice.org/60881 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-09-17New loplugin:externalStephan Bergmann
...warning about (for now only) functions and variables with external linkage that likely don't need it. The problems with moving entities into unnamed namespacs and breaking ADL (as alluded to in comments in compilerplugins/clang/external.cxx) are illustrated by the fact that while struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } returns 1, both moving just the struct S2 into an nunnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { namespace { struct S2: S1 { int f() { return 1; } }; } int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } as well as moving just the function f overload into an unnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; namespace { int f(S2 s) { return s.f(); } } } int main() { return f(N::S2()); } would each change the program to return 0 instead. Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c Reviewed-on: https://gerrit.libreoffice.org/60539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-13Support buffering SystemDependent GraphicData (II)Armin Le Grand
In this step I have changed all calls that use a B2DPolyPolygon and do filled graphics, added support for providing needed transformation which will -if supported- be used. Added buffering of SystemDependentData at B2DPolyPolygon for that purpose, see comments describing the current possibilities in the Gdiplus implementation. Moved lifetime creation/cleanup of SystemDependentDataManager to ImplSVData due to cleanup problems in the clang build Tried to use a std::unique_ptr to hold the instance of a SystemDependentDataBuffer at ImplSVData and cleanup inside DeInitVCL() right before ::ImplDeInitScheduler. This works in principle, but scheduler shutdown triggers ProcessEventsToIdle which leads to repaints and re-creates the buffer. Will now do exactly as was done with GdiPlusBuffer before, a simple local static incarnation and a call to SetStatic() in constructor Splitted SystemDependentDataBuffer and Timer due to different LifeTimes. Timer needs to be destructed earlier than SystemDependentDataBuffer, before Scheduler::ImplDeInitScheduler() is called from DeInitVCL() Change-Id: I2134e4346a183a4cee1be3428c51541cc8867c11 Reviewed-on: https://gerrit.libreoffice.org/60102 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-09-07Fix typosAndrea Gelmini
Change-Id: Idf3906894510d671c75c32a787ad315945b2c339 Reviewed-on: https://gerrit.libreoffice.org/60137 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-09-07Cleanup SvpSalGraphics LineGeometry creationArmin Le Grand
Target is to less modify the given PolyPolygons to allow better buffer/reuse. To do so, multiple steps need to be taken to make the creation of cairo_path_t correct and effective. Adapted AddPolygonToPath to no longer add a fixed PixelOffxet of (0.5, 0.5) for LineDrawing. Moved that at all places to set the needed linear transformation. Some places which know to work in DeviceCoordinates got directly adapted. The creation of geometry for polygon paints that use line and fill no longer offsets by that values for fill now (which should be better) Adapted AddPolygonPath to use the closed information from the given Polygon geometry - this is used in Win Gdiplus for years and shoud be safe Adapted AddPolygonPath to do correct PixelSnap when a ObjectToDevice transformation is used. This requires to have the ObjectToDevice transformation in the method and using it and it's inverse Adapted AddPolygonPath to support PixelSnapHairline which now needs to be supported in the VCL-layer. Adapted the BufferedData stuff accordingly (and saw that the old solution for this snap was not used - sigh) Corrected ::drawLine to correctly do PixelSnap if needed, version before would have lost it Change-Id: I5e8f71f7439b21f58561da5770b9054236a33235 Reviewed-on: https://gerrit.libreoffice.org/60083 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-09-01Fix typosAndrea Gelmini
Change-Id: I3da548adbbd8b24fe79779bdd8de70bdf7244035 Reviewed-on: https://gerrit.libreoffice.org/59845 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2018-08-30Support buffering SystemDependent GraphicDataArmin Le Grand
This is a first step to allow buffering of system dependent data, especially (but not only) for the system-dependent implementations of graphic output. For example, for B2DPolygon and Win output, it allows buffering the Gdiplus::GraphicsPath instead of re- creating it all the time. To support that, the change includes forwarding the current transformation to the renderers in SalGraphics. The current state in VCL is to transform all and everything to device coordinates at every single paint. I have currently started to do this for ::drawPolyLine implementations. The fallbacks for all systems will at the start of that method just transform the data to device coordinates, so all works as before. This may also be done for FilledPolygon paint in a later step, but most urgent is FatLine painting. An arrangement of shared_ptr/weak_ptr is used so that either the instance buffering (in the example B2DPolygon) or the instance managing it can delete it. The instance managing it currently uses a 1s Timer and a cycle-lifetime management, but that can be extended in the future to e.g. include size hints, too. The mechanism it designed to support multiple Data per buffering element, e.g. for B2DPolygon at the same time system-dependent instances of Gdiplus and Cairo can be buffered, but also PDF-data. This is achieved semi-automatic by using typeid(class).hash_code() as key for organization. The mechanism will be used for now at B2DPolygon, but is not limited to. There is already a similar but less general buffer (see GdiPlusBuffer) that can and will be converted to use this new mechanism. Added vcl/headless Cairo renderer to support given ObjectToDevice transformation (not to transform given B2DPolygon) Added support for CairoPath buffered at B2DPolygon, seems to work well. Need to do more tests Moved usage to templates suggested by Noel Grandin (Noel Grandin <noelgrandin@gmail.com>), thanks for these suggestions. Adapted Win usage to that, too. Converted Win-specific GdiPlus BitmapBuffer to new mechanism, works well. Checked, the manager holds now a mix of bitmap and path data under Win Added a cleanup mechanism to flush all buffered data at DeInitVCL() using flushAll() at SystemDependentDataBuffer Adapted Linux-versions of ::drawPolyLine to support PixelSnapHairline, for now in a simplified version that still allows buffering. This will also be used (and use buffering) for the Cairo-fallback in X11SalGraphics Change-Id: I88d7e438a20b96ddab7707050893bdd590c098c7 Reviewed-on: https://gerrit.libreoffice.org/59555 Tested-by: Armin Le Grand <Armin.Le.Grand@cib.de> Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-08-04crashtesting: bubble surface creation failure notification upwardsCaolán McNamara
e.g. on converting moz858095-2.svg to odg Change-Id: I1a222f1745cff9c4cb225f6c0c216072fb17b4f7 Reviewed-on: https://gerrit.libreoffice.org/58587 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-08-04Use more basegfx deg<->rad functions, instead of direct formulasMike Kaganski
Also make the functions constexpr. Due to slight changes in floating-point arithmetics (90.0 instead of 180.0, M_PI2 instead of M_PI resp.), results might differ in last digits (usually 17th decimal digit). This has lead to need to tweak char2dump's PieChartTest unit test. Change-Id: I20323dd7dab27e4deb408ea4181e390cc05e7cd3 Reviewed-on: https://gerrit.libreoffice.org/58583 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-08-02forcepoint#67 detect cairo surface creation failureCaolán McNamara
if e.g. too large Change-Id: I7de8748a5ed695c1b3ddc8c1358414f3acd68c94 Reviewed-on: https://gerrit.libreoffice.org/58453 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-07-31Add missing sal/log.hxx headersGabor Kelemen
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it. This is a continuation of commit 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 to be able to remove those unneeded includes. This commit adds missing headers to every file found by: grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG') to directory vcl Change-Id: I205fe0f4e80a66cd9c3b19f7e9716411da1d1cf5 Reviewed-on: https://gerrit.libreoffice.org/58221 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-03Use cairo's OVER operator to preserve transparencyKatarina Behrens
Change-Id: I1afae266a5308fa0dbf2488777ddb963e99199c7
generated by cgit (git 2.34.1) at 2025-01-14 16:10:38 +0000