summaryrefslogtreecommitdiff
path: root/basic
diff options
context:
space:
mode:
authorNoel Grandin <noel@peralex.com>2014-08-13 09:29:24 +0200
committerNoel Grandin <noel@peralex.com>2014-08-13 09:44:17 +0200
commit4155c28ae1700e853d598077a08a6ba6c1a94e06 (patch)
tree8c2b834374afd69cd240fbb3630e8bd718047a56 /basic
parentc5581d19c6c5d857c4117e72cb022dcfc9561409 (diff)
java: remove unused interfaces
found by UCDetector Change-Id: Ide8b3b5c9969048aff84eed16b9eea096abad349
Diffstat (limited to 'basic')
0 files changed, 0 insertions, 0 deletions
generated by cgit (git 2.34.1) at 2025-02-22 22:01:23 +0000
874ba85ec6f52ee37ddf'>Remove unneccessary commentsAlexander Wilms Change-Id: I939160ae72fecbe3d4a60ce755730bd4c38497fb Reviewed-on: https://gerrit.libreoffice.org/8182 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2014-01-27coverity#1078535 Division or modulo by zeroCaolán McNamara Change-Id: Iab9bb56ce7646955d2592d7e9abdaf829ee1ec78 2013-11-11basebmp: include <> for external includesNorbert Thiebaud Change-Id: I6f1f573662d5e759694c401598408df9fbb20be8 2013-10-31Resolves: #i123433# Detect pseudo-vertices at svg import...Armin Le Grand unify svg:d handling, correct svg:d import for relative sub-polygons in svg import; changed default for moveto writes for svg:d in ODF to absolute (cherry picked from commit f15874d8f976f3874bdbcb53429eeefa65c28841) Conflicts: basegfx/inc/basegfx/polygon/b2dpolygontools.hxx basegfx/inc/basegfx/polygon/b2dpolypolygontools.hxx basegfx/inc/basegfx/polygon/b3dpolypolygontools.hxx basegfx/source/polygon/b2dpolypolygontools.cxx basegfx/source/polygon/b2dsvgpolypolygon.cxx basegfx/source/polygon/b3dpolypolygontools.cxx basegfx/source/tools/makefile.mk basegfx/test/boxclipper.cxx basegfx/test/clipstate.cxx basegfx/test/genericclipper.cxx canvas/source/tools/surfaceproxy.cxx sdext/source/pdfimport/tree/drawtreevisiting.cxx sdext/source/pdfimport/tree/writertreevisiting.cxx xmloff/inc/xexptran.hxx xmloff/source/draw/XMLImageMapContext.cxx xmloff/source/draw/XMLImageMapExport.cxx xmloff/source/draw/shapeexport2.cxx xmloff/source/draw/shapeexport3.cxx xmloff/source/draw/xexptran.cxx xmloff/source/draw/ximp3dobject.cxx xmloff/source/draw/ximpshap.cxx xmloff/source/style/MarkerStyle.cxx xmloff/source/text/XMLTextFrameContext.cxx xmloff/source/text/txtparae.cxx Change-Id: I5171b4a3559ea116bea45152e1f2685666463635 2013-10-08Hanlde TopDown -> BottomUp conversion in basebmp DirectCopy logictsahi glik Change-Id: Ic6b94e8f01c0151741626f8b50d69597cc401852 Reviewed-on: https://gerrit.libreoffice.org/6155 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> 2013-09-27Off-by-one errorStephan Bergmann Change-Id: I84749158fb8dee3fec10869e0955177bbd917d59 2013-09-27Improve performance of copyArea(), especially relevant for mobile devices.tsahi glik 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> 2013-07-18fdo#62475 removed pointless commentsJelle van der Waa Change-Id: I85bee68e89c41642b2da72e11b695588b3dfe346 2013-07-18WaE: assuming signed overflow does not occur when assuming...Caolán McNamara that (X + c) < X is always false [-Wstrict-overflow] Change-Id: I63880bf27ab7e34eb9e0be682b39b80b71d65103 2013-07-12Turn basebmp::Format into a proper enumStephan Bergmann Change-Id: I4067c5039c7b5c74a1c144721dd7260de54dd2bf 2013-07-12THIRTYTWO_BIT_TC_MASK is the same as THIRTYTWO_BIT_TC_MASK_BGRAStephan Bergmann Change-Id: I917c4136614664a1816769300707f170312c885d 2013-06-04Add test for basebmp memory clobber.Thorsten Behrens 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 2013-06-04Detect copyArea trying to operate on overlapping memory.Tsahi Glik Equality test also needs to check if disjunct BitmapDevice instances might not actually share the same memory buffer. Change-Id: I09a93cb092a0039353be211ed053e991e7fe66f0 2013-04-24Don't point to inc directories that don't exist any longerTor Lillqvist Change-Id: If783897a60a545baf3968c5eeccf80a1e186bc51 2013-04-24Don't point to inc directories that don't exist any longerTor Lillqvist Change-Id: Ia160f0ee3e9480c60056d38bf11a6b139b53424f 2013-04-24gbuild: drop uses of removed packagesDavid Tardon Change-Id: I400fad08c0ae7b6b34bad63693f54856867e4dac Reviewed-on: https://gerrit.libreoffice.org/3502 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com> 2013-04-23execute move of global headersBjoern Michaelsen see https://gerrit.libreoffice.org/#/c/3367/ and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a 2013-04-15No need for Android, iOS or CROSS_COMPILING conditionals for unit testsTor Lillqvist We don't run unit tests when cross-compiling anyway and since d4ea8c6b7ee32dfbe1525cae45ad44d411052c33 the corresponding .mk files aren't even read by Make. Change-Id: Icbee9ad51841d515a551e67708d9594358ce7e71 2013-04-12Nah, I don't need a getOffset(), but I do need a getBufferSize()Tor Lillqvist 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 2013-04-11Fix documentationTor Lillqvist The value returned by getScanlineStride() is always positive even if internally the scanline stride is negative in the bottom-up case. Change-Id: Iaf394639d1e5a27d64b83f75c1d715a9860e492e 2013-04-11Add an accessor to get the offset of a subsetted BitmapDeviceTor Lillqvist Change-Id: I8a4a588287a90c6953b367bb02e075ea58f13a96 2013-04-11Add debugging printout of subsetting informationTor Lillqvist Change-Id: I6c37885823f14dcfbe750691dad27e094f46e66e 2013-03-27_USE_MATH_DEFINES is already taken care of by sal/config.hStephan Bergmann Change-Id: Ib0dab05534c34eb407f3acee3b4a3638a36bdddc