summaryrefslogtreecommitdiff
path: root/vcl/source/outdev
AgeCommit message (Collapse)Author
2021-02-24actually prefer DrawTransformedBitmap() if it's known to be fastLuboš Luňák
This partially reverts the logic of change 9d89d98d3349502b56d, which always made DrawTransformedBitmap() get changed to DrawBitmapEx if only translation+scaling was involved. But since that one may call BitmapEx::Mirror() that'll do pixel-shuffling, trust the DrawTransformedBitmap() implementation to do the right and efficient thing if it says so. Change-Id: If25b3d189ddd46b235e122e5e8d6f8079ec09f7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111248 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24add additional 0-1 alpha argument to DrawTransformedBitmap()Luboš Luňák
This allows the VCL backends the apply the extra alpha transformation as it sees fit, rather than it being done manually elsewhere (and even if the backend doesn't implement it, at least do it in one place in the function). With the document from tdf#136223, going from slide 2 to slide 3, this easily saves 10-30% of CPU cycles. As an additional bonus, using AlphaMask::BlendWith() rather than AlphaMask::Replace() makes edges of shapes noticeably more smooth. Change-Id: I036dc9b887d6def0c7cdad3982becabdc7cd5206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111247 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24simply use drawTransformedBitmap()Luboš Luňák
At least with Skia this is faster than GraphicObject trying to handle it manually, even in raster mode. Change-Id: If77d108751f5621878d4ea87a996c2ea0253d111 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111246 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-23use unique_ptr in OutputDevice::EmulateDrawTransparentNoel
Change-Id: I45f04c49055b0bead6b966ed4e682aec70c6e7a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111402 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-22Fix computation of aF fraction in OutputDevice::SetRelativeMapModeStephan Bergmann
...where cfff893b9c82843a90aac4ecdb3a3936721b74a0 "Move unit conversion code to o3tl, and unify on that in more places" had apparently switched the numerator and denominator arguments passed into the Fraction constructor. (And give the two values returned by o3tl::getConversionMulDiv less misleading names.) This had caused e.g. UITest_conditional_format UITEST_TEST_NAME=tdf100793.tdf100793.test_tdf100793 to fail in a (--without-system-cairo) UBSan build with > cairo-slope-private.h:50:22: runtime error: signed integer overflow: -2126627072 - 135139840 cannot be represented in type 'int' > #0 in _cairo_slope_init at workdir/UnpackedTarball/cairo/src/./cairo-slope-private.h:50:22 > #1 in _cairo_path_fixed_line_to at workdir/UnpackedTarball/cairo/src/cairo-path-fixed.c:517:6 > #2 in _cairo_default_context_line_to at workdir/UnpackedTarball/cairo/src/cairo-default-context.c:715:12 > #3 in cairo_line_to at workdir/UnpackedTarball/cairo/src/cairo.c:1743:14 > #4 in AddPolygonToPath(_cairo*, basegfx::B2DPolygon const&, basegfx::B2DHomMatrix const&, bool, bool) at vcl/headless/svpgdi.cxx:1291:13 > #5 in (anonymous namespace)::add_polygon_path(_cairo*, basegfx::B2DPolyPolygon const&, basegfx::B2DHomMatrix const&, bool) at vcl/headless/svpgdi.cxx:1821:33 > #6 in SvpSalGraphics::drawPolyPolygon(basegfx::B2DHomMatrix const&, basegfx::B2DPolyPolygon const&, double) at vcl/headless/svpgdi.cxx:1879:9 > #7 in SvpSalGraphics::drawRect(long, long, long, long) at vcl/headless/svpgdi.cxx:1059:9 > #8 in SalGraphics::DrawRect(long, long, long, long, OutputDevice const&) at vcl/source/gdi/salgdilayout.cxx:373:5 > #9 in OutputDevice::DrawRect(tools::Rectangle const&) at vcl/source/outdev/rect.cxx:83:17 > #10 in (anonymous namespace)::drawCells(OutputDevice&, std::optional<Color> const&, SvxBrushItem const*, std::optional<Color>&, SvxBrushItem const*&, tools::Rectangle&, long, long, long, long, ScDataBarInfo const*, ScDataBarInfo const*&, ScIconSetInfo const*, ScIconSetInfo const*&, std::__debug::map<rtl::OUString, BitmapEx, std::less<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, BitmapEx> > >&) at sc/source/ui/view/output.cxx:947:32 > #11 in ScOutputData::DrawBackground(OutputDevice&) at sc/source/ui/view/output.cxx:1116:21 > #12 in ScPrintFunc::DrawToDev(ScDocument&, OutputDevice*, double, tools::Rectangle const&, ScViewData*, bool) at sc/source/ui/view/printfun.cxx:594:17 > #13 in ScDocShell::Draw(OutputDevice*, JobSetup const&, unsigned short) at sc/source/ui/docshell/docsh4.cxx:2146:9 > #14 in SfxObjectShell::DoDraw_Impl(OutputDevice*, Point const&, Fraction const&, Fraction const&, JobSetup const&, unsigned short) at sfx2/source/doc/objembed.cxx:194:5 > #15 in SfxObjectShell::DoDraw(OutputDevice*, Point const&, Size const&, JobSetup const&, unsigned short) at sfx2/source/doc/objembed.cxx:141:9 > #16 in SfxObjectShell::CreatePreview_Impl(bool, VirtualDevice*, GDIMetaFile*) const at sfx2/source/doc/objcont.cxx:199:40 > #17 in SfxObjectShell::GetPreviewBitmap() const at sfx2/source/doc/objcont.cxx:110:9 > #18 in SfxPickListImpl::AddDocumentToPickList(SfxObjectShell const*) at sfx2/source/appl/sfxpicklist.cxx:120:46 > #19 in SfxPickListImpl::Notify(SfxBroadcaster&, SfxHint const&) at sfx2/source/appl/sfxpicklist.cxx:208:13 > #20 in SfxBroadcaster::Broadcast(SfxHint const&) at svl/source/notify/SfxBroadcaster.cxx:39:24 > #21 in (anonymous namespace)::SfxEventAsyncer_Impl::IdleHdl(Timer*) at sfx2/source/appl/appcfg.cxx:105:19 > #22 in (anonymous namespace)::SfxEventAsyncer_Impl::LinkStubIdleHdl(void*, Timer*) at sfx2/source/appl/appcfg.cxx:100:1 > #23 in Link<Timer*, void>::Call(Timer*) const at include/tools/link.hxx:111:45 > #24 in Timer::Invoke() at vcl/source/app/timer.cxx:75:21 > #25 in Scheduler::ProcessTaskScheduling() at vcl/source/app/scheduler.cxx:476:20 > #26 in Scheduler::CallbackTaskScheduling() at vcl/source/app/scheduler.cxx:266:5 > #27 in SalTimer::CallCallback() at vcl/inc/saltimer.hxx:54:13 > #28 in SvpSalInstance::CheckTimeout(bool) at vcl/headless/svpinst.cxx:210:53 > #29 in SvpSalInstance::DoYield(bool, bool) at vcl/headless/svpinst.cxx:463:21 > #30 in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:463:48 > #31 in Application::Yield() at vcl/source/app/svapp.cxx:530:5 > #32 in Application::Execute() at vcl/source/app/svapp.cxx:442:9 > #33 in desktop::Desktop::Main() at desktop/source/app/app.cxx:1586:13 > #34 in ImplSVMain() at vcl/source/app/svmain.cxx:196:35 > #35 in SVMain() at vcl/source/app/svmain.cxx:228:12 > #36 in soffice_main at desktop/source/app/sofficemain.cxx:98:12 > #37 in sal_main at desktop/source/app/main.c:49:15 > #38 in main at desktop/source/app/main.c:47:1 because aF was computed as 2540/1 instead of 1/2540 now. Change-Id: I092e6afe8cf2ea3145befccf075252b8e09f0967 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111347 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-02-14Move unit conversion code to o3tl, and unify on that in more placesMike Kaganski
This also allows to easily add more units, both of length and for other unit categories. The conversion for "Line" unit (312 twip) is questionable. Corresponding entries in aImplFactor in vcl/source/control/field.cxx were inconsistent (45/11 in; 10/13 pc; 156/10 pt). They were added without explanation in commit c85db626029fd8a5e0dfcb312937279df32339a0. I haven't found a spec of the unit (https://en.wikipedia.org/wiki/Line_(unit) is not specific). I used the definition based on "by pt", "by mm/100", "by char" (they all were consistent); "by pc" seems inverted; "by twip" was half as much. This accepted conversion makes unit test for tdf#79236 pass. Change-Id: Iae5a21d915fa8e934a1f47f8ba9f6df03b79a9fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110839 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-12always optimize bitmap transform to translate+scale if possible (tdf#138068)Luboš Luňák
Commit 828504974d70111e make OutputDevice::DrawTransformedBitmapEx() always call DrawTransformBitmapExDirect() in preference to explicitly converting to DrawBitmapEx() if the transformation wanted was at most translate+scale, in the hopes that these days the backend implementations work well enough. But it turns out only the Skia backend handles that without loss of performance. So always do the conversion to DrawBitmapEx() if possible. It's so simple that it possibly makes sense to always do this, regardless of the backend. Change-Id: I6eba68e672334c38433f53980f49400499f5d8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110716 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-19use more GetOutputSizePixelNoel Grandin
Change-Id: I90ac482ad2a3f372998f70ee6e65e6349567cba8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109564 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-19add OutputDevice::GetOutputRectPixel methodNoel Grandin
to simplify some and make an upcoming change less invasive Change-Id: I699b2be8fa35b2b72271eda4a0885f89a47b348a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109563 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-13vcl: migrate OutputDevice::SetGrayscaleColors() to Gradient::MakeGrayscale()Chris Sherlock
Change-Id: I125ad3db3ee30833022113da5d78dcf81d0f7edc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108374 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-01-12transparency->alpha in tools::ColorNoel
this just changes the Get/Set methods, the constructor and internal representation of Color is not changed. Change-Id: Idb6e07cc08bbaa5bd55b6bd4b585e648aef507b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109074 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-08vcl: move ImplPrintTransparent() from OutputDevice to PrinterChris Sherlock
Change-Id: I6950bdca72b93b34621e0b108c2c8060c59d98d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108247 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-08use more IsTransparentNoel Grandin
Change-Id: I3ef18a2601a51d56614b5da9b56e871bd33ec79e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-08vcl: migrate OutputDevice::DrawShadowBitmapEx() to BitmapShadowFilterChris Sherlock
Change-Id: I5d8b92d91530feed92dcdf2e384448b05eebdb0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108315 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-07set fill color when filling alphavdev area for gradients (tdf#138959)Luboš Luňák
When drawing a gradient to an alpha-enabled output device, make the area also opaque (=black in the alphavdev). Change-Id: I2ba1a598e0bf6291e5422253352a201e224af2b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108806 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-02tdf#74702 - vcl: introduce OutputDevice::GetDeviceInfo()Chris Sherlock
Change-Id: I02c9cc83fea330ed0ba1539b2682f75d33ba80fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108132 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-02tdf#74702 - vcl: introduce OutputDevice::CanEnableNativeWidget()Chris Sherlock
Change-Id: Idb43f57078702f64e9a80a2100b12fa0e6c3e155 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108130 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-29vcl: move local bitmap headers to inc/bitmap directoryChris Sherlock
Change-Id: I72cc28d4df8031e322daa50d79666cabcb6421a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108040 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-28Fix typoAndrea Gelmini
Change-Id: I56b701c83ddffb6628a80683e461102fcbd2db69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108387 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-28vcl: remove ancient SAL_DISABLE_NATIVE_ALPHA environment variableChris Sherlock
This environment variable was introduced in ed61578b3f9109bb, in 2006! I'm removing this code given it's older than my eldest daughter. Change-Id: Ia221f79f8ac76a1273520ff1cb151b6bfd71b216 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108373 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-28vcl: remove OutputDevice::ScaleBitmapChris Sherlock
Some time ago, in an attempt to remove a check on OutDevType I refactored some code into the function ScaleBitmap(). When I look at this more closely, I realise that I missed the point of the function. The code I refactored actually checked if subsampled scaling could be done. Thus, the function is inaccurate - it only scales *down* a bitmap, and in fact scaling is already done in Bitmap. Instead, I have now moved the function back into the code and replaced it with a virtual function that checks if the OutputDevice derived class can actually do bitmap subsampling (Printer is unable to do subsampling). Change-Id: I2e6bdbba0bf2153e0421efe6e05c05dd593a4e1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108323 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-12-26tools: add Color::IsTransparent()Chris Sherlock
This removes the need for OutputDevice::ImplIsColorTransparent(). Change-Id: I8f98199c5ce1c171c453b6897f27eacbd53f1eea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108248 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-24custom literal for Degree10Noel Grandin
Change-Id: Id13869138a622e62d9ffebf2c89bddccda6aff01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108238 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-24vcl: move access functions into appropriate bitmap access filesChris Sherlock
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx and BitmapWriteAccess.cxx Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx Change-Id: I7dcbe1d26c5b64d297658a6b809c93d7ad7f053d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108039 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-12-15tdf#138936 gradient missing under RTL from writer comment marginsCaolán McNamara
Change-Id: I57533f033f9528b7c89162967b392eb5abb4d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107750 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-08remove more no longer needed OpenGL-related codeLuboš Luňák
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07remove OpenGL VCL backend codeLuboš Luňák
It is by now practically unmaintained, even bugreports in bugzilla have been already closed for it. AFAICT this used to be really used only on Windows, where it's no longer the default. There's still some OpenGL code left, because there are still two other places that use OpenGL. One is OpenGL slideshows, which reuse some of the base OpenGL code (and I've checked they still work even after this removal). Second one is OpenGL canvas, which it seems has never been finished or enabled (or so it most probably should be dumped too). Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-03cid#1468270 Wrapper object use after freeCaolán McNamara
I think this is a better reflection of the original intent here before commit 1441ab9c75a2f0ac664983db22b681a1b602f8a9 fix possible SIGSEGV and commit 8f54136caa786523fd224f6c98fc8e7c45cd805d use std::unique_ptr for SalLayout Change-Id: Ib4ab63334e644a8136b9f7da20916715850563ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107171 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-02cid#1470369 Uninitialized scalar variableCaolán McNamara
and cid#1470372 Uninitialized scalar variable cid#1470364 Uninitialized scalar variable cid#1470363 Uninitialized scalar variable cid#1470359 Uninitialized scalar variable cid#1470357 Uninitialized scalar variable cid#1470355 Uninitialized scalar variable cid#1470354 Uninitialized scalar variable cid#1470353 Uninitialized scalar variable Change-Id: I4a28f0f375f9108f4c43da7074f85d1fdbb3ebff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107070 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-01DrawPolyLine/DrawPolyPolygon never called with null OutputDevice*Caolán McNamara
so we can remove some redundant nullptr checks, maybe making this a tiny less confusing Change-Id: Icba4ea1edd5b4883a294f52e0facaab631d94aed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106860 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-30split CopyBits into two functionsCaolán McNamara
to capture that if pSrcGraphics is non-null then pSrcOutDev is always non-null and that if pSrcGraphics is null then pSrcOutDev is unused Change-Id: I7b1ecb35724ef9a7afb4ab4021b33e9f00a9ea3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106808 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-28drawOutDevDirect always passed a non-null OutputDevice*Caolán McNamara
likewise: DrawOutDevDirectProcess ImplDrawWavePixel DrawOutDevDirectCheck and various members of SalGraphics dropping redundant nullptr checks Change-Id: Iaa1ab7c8a605361a7c9cce0aeee974eec9ff246e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106788 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-19Drop threshold for BigInt arithmetics from ImplLogicToPixel/ImplPixelToLogicMike Kaganski
Initially (since commit 8ab086b6cc054501bfbf7ef6fa509c393691e860) the code in vcl/source/outdev/map.cxx used BigInt arithmetics for overflowing cases. Then in commit 99a299383f2f16e5e8eefbb28e88a6a8f90ab95b, the code started to use sal_Int64, and ignored the threshold. Immideately in next day's commit 7bbb9d113a732851831dfadf8dee6b980dc0ab3b, the fallback to BigInt was restored - "when 64bit arithmetic does not suffice for mapping". Commit d563ac66ae12353c2c25d154fc9f493df67b3b8b made two modes - one using sal_Int64, and one using BigInt - separate (dependent on USE_64BIT_INTS), and introduced shortcut depending on threshold also into USE_64BIT_INTS code, dependent on SAL_TYPES_SIZEOFLONG ("#i55136# prefer native int math over int64"). BigInt code was dropped in commit b5100f8a1c76a921406ed3d3a54ba2479b011977. So now, after the functions take tools::Long, and it is 64-bit on _WIN64, it's incorrect to depend on SAL_TYPES_SIZEOFLONG for the shortcut. And making it dependent on sizeof(tools::Long) seems unnecessary, because now it's only active to 32-bit platforms with decreasing relevance, and the profit there is unclear, having to calculate threshold for each operation on all platforms. So this drops the threshold unconditionally, unifying the code on all platforms. If BigInt mode would be necessary, this should be reintroduced on all platforms, but for now we rely on 64-bit arithmetics, as we did before this patch. And while at it, replaced outdated uses of LONG_MAX/LONG_MIN with correct numeric limits for tools::Long, to avoid more BigInt operations. Change-Id: I8d6039c851d76712b391e754d3f78a97a8463f05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106121 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-16Instead of labs, use overloaded absStephan Bergmann
...more likely to pick an appropriate version for the involved integer types, esp. after the recent long -> tools::Long changes Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-16replace std::min(std::max()) with std::clampNoel
Change-Id: I76e34e8020d98292e8ffde387542b7029f85a42d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105754 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-14remove SalPointNoel Grandin
<caolan> that "SalPoint" doesn't really seem to to have a purpose except to highlight that "Point" is assumed to use LONG under windows and can be passed unchanged to those windows drawing apis <caolan> so I guess remove SalPoint entirely, use Point instead, and convert to "POINT" under windows ? Change-Id: Ic15a7f4516e2075a228fa65cac4e8494d5b3abaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105634 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-13properly clip native VCL gradients (tdf#137563)Luboš Luňák
If I'm getting it right, OutputDevice::InitClipRegion() sets mbOutputClipped = true if the entire output would be clipped, and it doesn't call SalGraphics::SetClipRegion() at all, instead OutputDevice draw calls are supposed to avoid the drawing entirely. But while the polygon fallback in OutputDevice::DrawGradient() does so, the call to SalGraphics::DrawGradient() didn't. Change-Id: Ib93bcad98534a3a3d9be26cdea11def51c796f00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105759 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-13Revert "remove BigInt::operator tools::Long()"Noel Grandin
This reverts commit 1397a1c8e4995b0dd336478e564880fe8ad91d1d. Reason for revert: Some discussion required Change-Id: Id39ee8260790e0722c5bf8338b0b76ca34da83d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105539 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-12use Point direct and drop a reinterpret_castCaolán McNamara
Change-Id: Idd8901225ddb687a2d1b8b5ba4069b40f218191f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105603 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-12remove BigInt::operator tools::Long()Noel
which was introduced in commit adf0738d2dbfa742d0e9ef130954fb4638a8e90d Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Wed Jan 3 14:25:15 2018 +0200 long->sal_Int32 in BigInt presumably to make the conversion easier. Instead just fix the call-sites to select a better conversion, BigInt only returns 32-bits of precision anyway. Change-Id: I2e4354bcfded01763fe3312a715ef37800297876 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105602 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make sure mpAlphaVDev is drawn when drawing lines (tdf#137974)Luboš Luňák
4deadc3c78949c18bb886eb1f66caa8f3cd7a2df made OutputDevice::DrawLine() use SalGraphics::DrawPolyLine() in more cases, which revealed that the the function was bailing out after the call and not drawing also to mpAlphaVDev. Change-Id: I1145d3684835b536737311294edfc566d5eb9025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105553 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-11convert more long -> tools::LongNoel
found by grepping and changed by hand. Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11Improved starmath colordante
Color.hxx has now documentation ( even if it is quite obvious if you know RGB standar ). Color.hxx has been reordered in more coherent order, but kept format. Some changes on Color.hxx dynamics. Color.hxx starmath colors list Now colors are managed by starmathdatabse. The path is open for simple addition of colors, there are no more infinite switches with color tokens here and there. To add a color, just put it in Color.hxx and register it in starmathdatabse.cxx. Do not forget to change array size in starmathdatabase.hxx. Now mathml supports RGB colors in #RRGGBB format ( import and export ). New colors have been added. Only the HTML Css1 are available via UI. New colors will be added. I intend to finish Css2 and dvipsnames ( latex colors ) on posterior patches. RGBA command has been unlocked for compatibility reasons. However will be displayed as RGB. Added color #RRGGBB. Improved qa color test on mathml to test RGB on mathml. TODO for someone on the UI team: - Add a color picker. - If it is a color with name: - It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" " - If not: - It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "+ colorvalue.getRed() +" "+ colorvalue.getGreen() +" "+ colorvalue.getBlue() +" " - Note that those will habe eType with value TRGB or TRGBA. Change-Id: I47af37bd191b3099e8e6e08e7a5fb1a8a227bbf2 Change-Id: If971473ddcc34739439818dba9a62ca3494a4473 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin
This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-05N8BitTcMask is unusedNoel
since commit 77809fba7d4bf5e0b604ffa3937c18d5530c2d56 Author: Luboš Luňák <l.lunak@collabora.com> Date: Fri Oct 9 19:28:49 2020 +0200 implement ImplFastBitmapConversion() for 8bit gray source Change-Id: I730aef10c1705ae6d3141014228cf79b8bfa3c63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105305 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-29tdf#137643 alternative solution to activate embedded fonts in one batchCaolán McNamara
Change-Id: Ib5ffb2b8a31f237d5d2e465bf3f777590e0bfade Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104947 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-28tdf#137643 Revert "lock refreshing font data when loading a document"Caolán McNamara
from tdf#69060, to replace with an alternative solution This reverts commit 98d71c4e0847797a4ba9229a8e6d832a8a3d5e0f. and This reverts commit 64d8e5f8db70f4f913abb902b41f4cff8dd1cdad. Change-Id: I384e994b54aa1bfc735c6ab591b9b1410058451f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104716 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-28convert some more long -> tools::LongNoel
grepping for stuff in template params this time Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-06-18 18:47:20 +0000