Age | Commit message (Collapse) | Author |
|
Use #pragma once instead of header guards
Change-Id: Iba43f2103628ed184933cf2611991e7aef9f0173
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173369
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
regression from the transparency->alpha work
Change-Id: I2aaf8262191ca6136f87c59629e95bd9a7e7e419
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174991
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
and
cid#1607946 Overflowed constant
cid#1608526 Overflowed integer argument
cid#1608611 Overflowed integer argument
Change-Id: Iec21df2f3d7dc8fba3872c6a70466ae12026a49d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174557
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I7b927cd3dade5bc73039541c3ec8c72a9de400b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172009
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
and
cid#1554745 COPY_INSTEAD_OF_MOVE
cid#1554758 COPY_INSTEAD_OF_MOVE
cid#1554766 COPY_INSTEAD_OF_MOVE
cid#1554771 COPY_INSTEAD_OF_MOVE
cid#1554787 COPY_INSTEAD_OF_MOVE
cid#1554802 COPY_INSTEAD_OF_MOVE
cid#1554820 COPY_INSTEAD_OF_MOVE
cid#1554828 COPY_INSTEAD_OF_MOVE
cid#1554829 COPY_INSTEAD_OF_MOVE
cid#1554832 COPY_INSTEAD_OF_MOVE
cid#1554842 COPY_INSTEAD_OF_MOVE
cid#1554885 COPY_INSTEAD_OF_MOVE
Change-Id: I43ec20250a04dc087f3d7fdeafc75f0c1dd0de25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170542
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
This removes the mpContext member variable from ImpGraph, which
also make {Get,Set}ReaderContext on Graphic obsolete and is also
removed. GraphicFilter and other code is adjusted and simplified.
Change-Id: Icd1927d7b1bd4624b523d0f49a4343911ec6cd0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165214
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I5b6ee5bda0c5ff69d297f7f8e87d4c3f3d21791c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167470
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I7447e649dc3ef4e51242f69c7486a3e84e103d2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166159
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
And use it when assigning to tools::Long
Change-Id: I0814d7bac9cdd48191ba69c64e3b12a4973b3417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166071
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Graphic memory manager was changes so that it can work with any
object that implements a specific interface (MemoryManaged). With
this it will be possible to use other objects (that take a lot of
memory) to be managed by the manager. It is also a first step to
move memory managin responsibilities away from Graphic and move
it into the specific objects instead (BitmapEx, Animation and
VectorGraphic).
Change-Id: I7638bd89a1c9ece5c4bc95b506d2192492894ef3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164958
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
- vcl change UNO type of UnoGraphicProperty::BitsPerPixel to sal_Int8 instead of sal_uInt8 which maps to BOOLEAN causing Basic to convert
non-0 values to True
- basic add CppUnitTest since thats where the problem was occuring
Change-Id: I0111199151fb5e001b6362e1359ad90bb039f064
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163899
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove
non-const Sequence::begin()/end() in internal code, 2021-10-15) and
commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and try something a bit more generic
Change-Id: I1d8256576cd02f0a589df350ba7b53059dd586a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161250
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I3cecd622aa04d842a449b4bfd6c55d0b8b96aabf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156992
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Having it subclass Bitmap encourages confusion in passing it around, and
I need the extra type-safety for my work on merged-alpha
Change-Id: I35819f9b8ee609cbdaf865563c78531e397b529b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160235
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
into the two entire separate cases they want to handle, there is
no reason to mix the two different cases like this.
Change-Id: I38e99e7ad6168a84e7a744f61407887825158902
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160248
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
using the color bitmap __and__ the alpha from another BitmapEx
is equivalent to just doing a straight copy/assign
Change-Id: I134ab8a1197ed538823afc4a8cd28b3d5986c6b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160019
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iea16260cd152e1c495e7713ada812265dbb5b702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158598
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
with lots of images, we seem to spend lots of time calculating
CRC. Replace the vcl checksum/CRC with rtl_crc32 in sal/, which
forwards to the zlib implementation, which has all kinds of
nice SIMD code for performance.
Change-Id: I295e2ee91b3450fa558b06e67aac0fbb20b85f52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158529
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
avoid doing some extra Invert() operations by creating an AlphaMask
instead of a Bitmap to pass to the BitmapEx constructor.
Change-Id: I1af3a5e65010b346fa0d0c56836d567e51c9b58b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158106
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8fbe02547d5045cfdb5021720b10ddd10106209a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155750
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I8c0e513d36c087e9ea8019325cdb3122bec744be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155743
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
(Second attempt at landing this)
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.
Add a couple of new Color constants to make the intention
of the vcl code clearer.
Notes
(*) On macOS, tweaking the logic in CreateWithSalBitmapAndMask
to more accurately reflect the requirements of the
CGImageCreateWithMask function seems to fix some
tests.
(*) The vcl code does not properly support gradients
with transparency. So the previous code was wrong, and this
change is going to result in slightly different wrongness.
Change-Id: I9e21c2e98d88ecfdc5f75db13bd1ffff7c38db98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114168
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which will help avoid ambiguity in method calls in an upcoming patch
Change-Id: Ic7607ac7d95559e0942a84fb3226cfdd6ade22bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154146
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
rather than writing a bunch more code, extract the common part from
comphelper::SequenceInputStream into a new base class
Change-Id: I0d3561e3ca2e748b904128e3b5955e27196d7170
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151943
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
We can easily accumulate a large number of in-memory graphic
objects, and swapping these as well as the un-compressed
images can become important.
For now we swap out the container when the image is swapped
out, however it seems unlikely it will ever need to be swapped
in again.
Despite the shared pImpl, we retained the reference counting
on the underling vector to keep this immutable while we hand
out a MemoryStream reference to it.
Change-Id: Ib7ca45afb8499460b1852461f7c11afca3f3cdfa
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151359
Tested-by: Jenkins
|
|
Change-Id: I3543b7e251fe6076ad1875bc49abfbe747f45999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150813
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Hide the SvMemoryStream implementation detail better - this
could be served from a file in future. Also couple lifecycle
of the SvMemoryStream to the vector backing it.
Change-Id: Ia9b28b57b8df4ce57286effd4d1753bf345fc10e
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149917
Tested-by: Jenkins
|
|
Change-Id: Ic8dbf0afdb96a0f1be210eedfbd12ef6467dd29f
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149916
Tested-by: Jenkins
|
|
Change-Id: Iab24e8d18bf7badbca672fbdbf455f78d08f41a0
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149905
Tested-by: Jenkins
|
|
Change-Id: I2eeb07780e3581eea29a9ad98b493de4e78a5d65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149745
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Being able to trigger some more aggressive memory saving is
useful in for both online and mobile.
Change-Id: I9b91c9fe9eecec06c75112595deac0bfeb94c144
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148624
Tested-by: Jenkins
|
|
since:
commit d062f097cc48bd53247b7fb0c677d90fcc430ab7
Date: Wed Mar 8 02:14:11 2023 +0300
Simplify usage of BinaryDataContainer
It is always used to store data read from streams
Change-Id: I33d237a801b1cdf47b85b3fd3522c398ba08068b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148524
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
It is always used to store data read from streams
Change-Id: I613bc446eaadf98d2b1c012002d38f23d79a40ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148450
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iecbae3570851784f0da75fd2899daf620c8e4c06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145994
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...rather than on the legacy OWeakAggObject.
It was found that e.g. Graphic, deriving from GraphicDescriptor, was
implementing queryInterface in a way that is incompatible with XAggregation
protocol inherited via OWeakAggObject. It looks like no code actually made use
of the XAggregation offered by this class hierarchy, so the easiest fix for that
queryInterface implementation appears to switch from OWeakAggObject to
OWeakObject.
Change-Id: I54514db32b731b9fa83831a1071da6f665fdf25e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145891
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifdef69448558f4c5d6902188208d3eea1a080334
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145506
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to ease the reading of code related to an upcoming patch to convert
transparency to alpha, since there is already a GetAlpha in Color.
Change-Id: I1af0f8f6dd94acfe4673c8556c7aff6c20da3f7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145209
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The nAlphaTo parameter was actually transparency. Change the
implementation and the call sites to actually use alpha.
Also remove one of the calls in Graphic::colorChange, because if the
BitmapEx has no alpha channel, the call was going to do nothing anyway.
Change-Id: I0bf27835b62596ac7c497c8606ceba04fcf859a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145205
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
like we do when we get one from Image so we can treat these with the
same shortcuts we do for Image to have the option to pass the
underlying svg data to the final widget it ends up in
Change-Id: I13a5aecc73821e88f1958e1e1e9e7322628cce6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142484
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The emphasis is not quite right. An animation is made up a sequence of
*frames*, not bitmaps. A frame includes such things as position, size,
timeout till the next frame *as well as* a bitmap.
Note: had to regenerate a bunch of precompiled headers
Change-Id: Ib1959452653857555f41e01ac0151d08c41a3b1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/76460
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id8b3c2bcf0bf4be5aba2812b0edda479bc20c6a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139683
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
It appears at the start of Graphic::colorChange aBmpColorFrom &
aBmpColorTo gets initialized with wrong colors. Instead of {R,G,B},
they get initialized with {B,G,R}.
Instead of bitshifting use the ::Color constructor so that it is
initialized correctly.
For ooxml import adapt tolerance values of the image format in an
attempt to get similar results on how the results appear in
PowerPoint.
Change-Id: I1fa901691512de82936dba0e47158b7e0ca2223e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139203
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
GraphicFormatDetector and GraphicDescriptor have duplicate format
detection code so now GraphicDescriptor uses GraphicFormatDetector
functions instead to detect the format for SVG files
Change-Id: I5ababbd43ece4e8c08c5833895dc0b56ad467f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138102
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
GraphicFormatDetector and GraphicDescriptor have duplicate format
detection code so now GraphicDescriptor uses GraphicFormatDetector
functions instead to detect the format for WMF/EMF files and their Z
compressed counterparts WMZ/EMZ
Change-Id: Ia054c782320923aaa0c2c8bda2f33c27c3b123d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138067
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Regression from commit 78e25558e86188314b9b72048b8ddca18697cb86
(tdf#106059 PDF export: create a reference XObject for JPG images with
PDF data, 2017-02-23), once a PDF image was inserted to a document, an
encrypted PDF export lost those images.
The reason for this is that we started to preserve PDF images as vector
data with the above commit, but this means we copied over PDF objects
from PDF images to the export result as-is, so encryption was not
performed for them.
Fix this by separating the write of the PDF object headers, stream
content and object footer and then calling
checkAndEnableStreamEncryption() / disableStreamEncryption() for each
object, even if it's not something our PDF export created but comes from
a PDF image.
Note that when existing PDF files are signed, PDF objects are also
copied into a vcl::filter::PDFDocument, but such PDF images are never
encrypted, so it's fine to have stub implementations in
vcl::filter::PDFDocument.
Change-Id: I2f74b9f51cd35b4319221532ca890e197bab9cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137242
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I2702e716dc669ffbb870d36d060e110288d7a744
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137043
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9ddb786eb88213c53cf53067ced6899ca40ac6e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137000
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The name "extra data" doesn't really describe what this field does. What
it actually does it to specify what animation renderer should be used.
Change-Id: I1e705ba89d09ceb41a8649c8947225c7b6816e7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/76403
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|