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. Cleaned up some, but something like
grep -FwL sal/log.hxx $(git grep -Elw \
'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF') -- \*.cxx)
shows lots more files that potentially need fixing before the include can be
removed from rtl/string.hxx and rtl/ustring.hxx.
Change-Id: Ibf033363e83d37851776f392dc0b077381cd8b90
so we could create bitmap devices that have the same stride that cairo expects,
provide getBitmapDeviceStrideForWidth to get a default value
Change-Id: I7ecc6f54a734b3f6bed59c699ac3b482c4ad7c47
This was some staggering proportion of tiled rendering documents
with complex clipping; it seems 'clear' is not what memset is for
1bit clip masks.
Change-Id: I9142ffb7d7016603feb7782d6f03b9992b9494e3
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
vigra::copyImage89 does not handle copy areas in the same image so the
code checks whether the src and dst are same buffer and directs it to
scaleImage() which is very slow. The whole concept of pixel accessors
is a huge overhead in the case of direct pixel copy (vigra::copyImage
is also using pixel accessors). The idea here is to identify when
direct memory copy is applicable (when the format is an integral
number of bytes per pixel, src.size==dst.size, and
src.format==dst.format) and use direct memory block copy and not
pixel-wise copy. The result is 100x faster than the vigra
implementation. This direct copy is also handling the case when the
src and dst are same buffer by copy it from bottom to top when needed
and using memmove() instead of memcpy().
Change-Id: I8ec589463d6386db82777a916371a5ebbf9e2d50
Reviewed-on: https://gerrit.libreoffice.org/5707
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Cloned bitmap devices may share the same chunk of memory, thus
risking overwriting our own data when we copy stuff around. Now
caught from unit tests.
Change-Id: I33b1a0b5d17550cbc6eced8bae01ae5ab9ebce9d
Equality test also needs to check if disjunct BitmapDevice instances
might not actually share the same memory buffer.
Change-Id: I09a93cb092a0039353be211ed053e991e7fe66f0
To properly handle subsetted BitmapDevices in the iOS vcl backend I
seem to need to know what the size of the full BitmapDevice is.
I wasted at least one day on desperate hacking and debugging, trying
to wrap my head around a misunderstanding of what a subsetted
BitmapDevice is. I thought it involved coordinate offsetting...
Change-Id: I83bf1a7d75ce192aaf21f1e408008e362fd6c6e6
For Android (and perhaps iOS) we need a 32bpp format with channels in
RGBA order.
Rename the (basebmp-internal) 32bpp PixelFormatTreats_* typedefs so
that the channel order in their names matches the memory order of the
channels.
Change-Id: Ia8a74f6d44e0a2cffdf66a05ddf8fc7d6ae2a263
Slight tweak of d0d62edf3f398e9ddb2fd0f1f5fbe1dd0393ff47 - getPixel()
and getPixelData() are complementary functions, similar in spirit
to const and non-const getters. Added unit test for it to avoid
flagging it for removal again.
I removed 2 unused headers.
I also stopped delivering a lot of headers that no one outside of basebmp
cared about.
I also removed the unused methods:
basebmp::BitmapDevice::getPaletteEntryCount() const
basebmp::BitmapDevice::getPixelData(basegfx::B2IPoint const&)
The Cohen/Sutherland clip flag routine was not aware of B2IBox,
thusly yielding incorrect line clipping for BitmapDevice software
rendering. Cleaned that up, added some more unit tests around the
problem, and removed the now-extraneous maLineClip member from the
bitmap device.
