Age | Commit message (Collapse) | Author |
|
Change-Id: Ib700887ca79f423c65dfb75eea36bbfd808fa172
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114976
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Rather use a proper alpha channel if we need transparency.
This is another small step towards merged alpha in our vcl
layer.
I suspect the intent in a lot of this code was to save memory.
Which have been a thing way back then, but these days our
backends mostly end up doing a copy-and-convert to a real
alpha channel anyway, so the existing code is actually
now a pessimisation.
Change-Id: I4a2bcbb2f76b841f05bc00580f364492829c69de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114808
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
An attempt that did not find anything convincing enough to finish it up
and make it permanently active.
So just leave it in /store for now.
Change-Id: I1750e177655a4a510da100f880ba81bf762be277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114742
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
So that we have fewer cases to deal with when we transition to
32-bit bitmaps.
(*) rename maMask to maAlphaMask, since now it is only being used
for alpha duties.
(*) drop mbAlpha and mbTransparent to simplify state management,
the only thing we need to check for alpha is if maAlphaMask is
non-empty.
Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Some presentation animations temporarily cause extensive zoom matrix
and Cairo doesn't take that well.
Change-Id: I1eb6d63fc2dcde6553bc8cc7ab967532d085a579
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114344
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Revert "convert internal bitmap formats transparency->alpha"
This reverts commit c181e510c5f5e74f1f6824b64637849aace9ae63.
and later fix up of
Revert "tdf#141504 qt5: ugly images"
This reverts commit e7424ff25a724ea5bb54b2282d5c3cbf74c92053.
a lot of places are still working int transparency values
and not opacity
Change-Id: I31342cdb76629acbaebfcdfa385407d3291fe06f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114150
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
We can cast the PixelFormat enum to int for the same information
and we can use the enum to reduce ambiguity when possible.
Change-Id: I6ea648139465568cdeb12e5f5f75c7b609365bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113188
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
since we have already removed the 4-bit internal bitmap formats.
Change-Id: Ie481aaa8e25642a47e30beb6f37e2d3beda304e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113412
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
IRC chat:
<quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap
has the same problem as Graphic and the reason why you dropped that
commit 7334034ae93b49fc93b5859a3c047a319d138282
"drop Graphic::operator bool"
<noelgrandin> quikee[m], hmmm, good point
<noelgrandin> maybe I should just drop both operator bool and
operator! in favor of IsEmpty
<quikee[m]> noelgrandin: I don't remember what the problem is I just
remembered we dropped it Graphic :) sure, dropping everything for
IsEmpty is probably the best
Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Bit count for the image is a numeric value (sal_uInt16) but only
a handful of values make sense - namely 1,4,8,24 and 32. This
replaces the numeric value with an enum, which only accepts those
values and checks the correct values are used at compile time.
Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Idcae44440a197f6b3b824cbbac430e370964ac25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112368
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
By convention, it should be the first include in C/CXX files;
so use of pch should not break that.
Change-Id: Ic329c5f39e8f48ad1778724368e262e48972342b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112123
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
where we might be holding something newly created by pointer
instead of by *::Reference
Change-Id: Ife6f7acae4252bf56dcdeb95d72e43c523444f97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112138
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I just used ./bin/update_pch.sh
Change-Id: I06a7f36eb4c511b8d6c6477fd87e57f0d9702457
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112097
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: If32c6f6d3618c134cfb2ac89e827491525c34687
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111811
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7807e2e7fa7f9a68d36c103d8b1dba708350f8aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111745
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
Image formats and graphics APIs use alpha, not transparency,
so change our internal formats and data structures to work directly
with alpha, so we don't need to modify data before we push it to
graphics APIs.
Change-Id: I537f77f79e83876be11d787901df42710d190842
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108919
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I77e4d29b2911bb86c383afbf977d241eaa8cd341
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111307
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic802d6593db053bb31c3463e67b63399b5f26d67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111001
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If38a5ad4e5db287a3105bb0faca031bc98c47fd3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110979
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I77d071e3536659c44ca8565bc2e5d90c53f8ee7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110847
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
And leave the work to the function instead of trying to handle it
manually.
Change-Id: Ia1ede2378d461a57e5c338ab5cabe908c320b2b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110599
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ie8d28702bbae6c76924745a5a773393f1b831012
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109706
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: Ida34f9428d342cbe7f89f7bf40688c71cdba30c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109299
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Id88f2a82bf2651e8b5895aa330f32b71ff5b0e48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109546
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic3006e3f73c5b1233076706d5982fefe12b8d511
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109448
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1fe9311871724ff8b7b8960f5dba6e890198565c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109211
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
The VCL OpenGL backend code has been removed, so the settings
for it no longer make sense.
But there's still the code for detecting if OpenGL is broken,
and that one makes sense to keep. It turns out other OpenGL code
(such as slideshows) doesn't even use that, so turn this into
a new DisableOpenGL option, make OpenGL-related failsafe code
set and use that, and OpenGL code should use
OpenGLHelper::supportsOpenGL() to make sure OpenGL use is not blocked.
Change-Id: Iec83f204e89bfb0b6eea13be77da8f0f4727a074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107398
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
I fixed the assert with 4eb816de71f1310a3a5d9803f7355849e6273439 (and
follow-up commits), so this is no longer needed.
This reverts commit 76b43425d764fbc9bf4dac52054b1d94344f26b0.
Change-Id: I85dec14cc8858b7168532661de9ca77c31802a62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106962
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifcdecb0a60f5a4b09acc83ed38b6d1ec46765ba6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105649
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
VCL implementations may have an optimized implementation,
and with Skia decomposing to polygons also causes drawing problems.
Change-Id: Ib1e317c627f01a43b77b9a8ee2335f4e319c37e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106016
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...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>
|
|
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>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Iac1e7802dbe1efa01c2befdd10406231788d4fc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105315
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
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>
|
|
The values returned from GetNativeSurfaceHandle are only used in
cairocanvas::CanvasBitmap::getFastPropertyValue
(canvas/source/cairo/cairo_canvasbitmap.cxx), whose consumers in turn are (at
least the ones I could identify):
* OGLTransitionerImpl::setSlides
(slideshow/source/engine/opengl/TransitionerImpl.cxx), passing the
values on to X11SalObject::SetLeaveEnterBackgrounds, which extracts the
Pixmap value to pass it on to XSetWindowBackgroundPixmap.
* X11SalBitmap::Create (vcl/unx/generic/gdi/salbmp.cxx), which extracts the
Pixmap value to pass it on to X11SalBitmap::ImplCreateFromDrawable (as a
Drawable) and to XFreePixmap.
While Pixmap XIDs are apparently 32-bit in the X11 protocol, see e.g.
<https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html>, Xlib and the
underlying /usr/include/X11/Xdefs.h appear to be somewhat confused whether the
typedef for XID should be unsigned long (presumably stemming from times when
long was universally 32-bit) or CARD32, see e.g. <https://gitlab.freedesktop.org
/xorg/proto/xorgproto/-/blob/master/include/X11/Xdefs.h>. So conservatively
stick to a 64-bit type here, even if it should only ever contain 32-bit values.
Change-Id: I26c3a2ff74cef092042a6e3648cd9a6f4a9e3aac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105144
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ide4014348d51f0b5f59e1e91b8d41c7748853254
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104608
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Perhaps AA may not look good with GDI or Xlib VCL, but with Skia
it is fine (and if it's not, I'll fix it).
Also avoid the repeated copy&paste.
Change-Id: I7aa60ae1e1c8a2ab4fa93d08ab0dfeb23c9c2cb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104437
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|