Age | Commit message (Collapse) | Author |
|
Caused an assertion failure: "sal/osl/unx/process_impl.cxx:167: sal_uInt32
osl_getCommandArgCount(): Assertion `g_command_args.m_nCount != 0' failed".
Change-Id: Ib01e0312e328f751c9353aab95dceb977b818b0c
|
|
Change-Id: I244eb4877801ceb0ff22e8591dccd6b801d00d68
|
|
Change-Id: Ic96487afce64bfb0c1dfcc03c088e5d6e1b34ad3
|
|
Change-Id: I1bdd0fe0d27674da69a61bd8b438f0c9b050a337
|
|
Change-Id: I099bff66a7796a5cf18e37e445467bdfb33de602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
means "work in progress", pretty long since 2000.
|
|
|
|
Removed XOR clipping version of ClipAndDrawGradientMetafile. Because it
has been removed, the other version isn't really needed in it's own
function so I've moved it back into DrawGradient.
Change-Id: Ib1519a019061c8c71183db63e5c11681bcad4cc4
|
|
Change-Id: I2b353435b29046b05acbb1193fda168309e01f4b
|
|
Change-Id: I7060802164989c2797d4abea29a378eaa3a54b41
|
|
2 "else if" with same condition, one of them is wrong and it seems here the first one.
More details here: http://nabble.documentfoundation.org/Cppcheck-reports-else-if-condition-matches-previous-condition-vcl-td4104270.html
Change-Id: I818cfa879a41c5818c429acc1645b1ee1f8b5103
|
|
Turns out that the two versions of DrawGradient in OutputDevice are
almost exactly the same in every way, except one deals with a rectangle
and the other with a PolyPolygon. So I just convert the Rectangle into
a PolyPolygon and use the PolyPolygon function.
Now that the functions are unified, the need for a seperate function
to clip and draw the gradient is no longer really required, so I've
merged this back into DrawGradient.
Change-Id: I94d4af1bb7dd900495672f0c0481dc9a1083ff67
|
|
If the polypolygon that we use for DrawGradient is a rectangle, then we
need to 1) expand the gradient rectangle to avoid missing lines on the
right and bottom edge, and 2) we should pass NULL as the clipping
parameter for ImplDrawLinearGradient and ImplDrawComplexGradient.
Change-Id: I8d8289ace069b5c500db59d1a2addfcea8388dfb
|
|
We should reduce OutputDevice's clipping region to the bounds of the
polypolygon. To do this we run OutputDevice::Push(PUSH_CLIPREGION)
to have it set the clip region of the device, then intersect the clip
region of the device with the bounding rectangle.
Change-Id: I58ff5d1def1eca3c1213c7fd2d6a7205b70cdd01
|
|
Change-Id: I2905e98425b9991d6138ab0adc15083d313ca445
|
|
Change-Id: I150cbe9ca96f0fb9a6b1116f79a0711d78252ba5
|
|
Change-Id: I1eac909bfa0ff3a945c294a2d6f4cb1d454ac985
|
|
Change-Id: I340eb9e7550083818874fed90d0a94e15fd597fd
|
|
Now that we have removed XORClipAndDrawGradient, there is no need
for the function ClipAndDrawGradientToBounds because the sole
purpose of that function was to work out whether the system should
use XOR clipping or not for gradients!
Change-Id: Id29b804054dfc30a9cc350bf4958ea3b2420e272
|
|
Only access pKey after we've set it.
Change-Id: If0be3972c36b3da9d9a456fe3746224372a443dc
|
|
Change-Id: Ieaa787afd7cc622b4750a2ee8f17f6dad934ba63
|
|
Change-Id: Ie5a35f68041a9c65658b9ce569ed3202c8a72ecb
|
|
Change-Id: If1dcb577d2dcc6477f43ad1be0e970e08d9093c6
|
|
The whole of svpbmp.cxx and svpvd.cxx are nowadays ifdeffed out for iOS.
Change-Id: Iac1f66457dc315ea86f86d12e1f6eb5bf4bcbb8c
|
|
Change-Id: I966189a74414ea83b2ec7f5035cd7c9d4d674179
|
|
But, has no visible effect, doesn't fix rendering problems.
Change-Id: Ic79b38b665e357a2dafe679c35979250c3bff538
|
|
Change-Id: I68e5aa92cb6ccff8b8d077c311d2ebc3f4676ae7
|
|
Change-Id: Iae712de4efbbe254ba381a036e2c84d5e27d5e40
|
|
Instead, act as if it was true on all platforms. Don't do XOR clipping on any
platform. Simpler code is better code, and XOR tricks are generally very much
out of fashion these days, I have been told. Didn't seem to have any visible
ill effects on Linux at least.
Change-Id: I6192006c77a4a81363ec7b3292f72d512d5e9b53
Reviewed-on: https://gerrit.libreoffice.org/8901
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: Ifd6a9897e3ebf978968efed79a478fa72cebe51a
|
|
Change-Id: If60a02f42a64ac60fb5be1072bf34efcbfa3cc6b
|
|
Change-Id: Ie3cfd1427dfe668c4cf682efa1f728dea764d277
|
|
GetNextGlyphs could only deal with 1 glyph at the time
and was recalculing a lot of thing while iterating on the glyphs
This is not just a performance issue.. the notiong of keeping
per run glyphs information will be useful to re-establish the
proper support of glyphs display positionning by SetDXArray()
which today is completely ignored, in favor or letting
CoreText spread the extra free space itself.
Change-Id: Ib267c3e490619b650d4149f4b15b5758802942ba
Reviewed-on: https://gerrit.libreoffice.org/8879
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Icf3cc0ece477a1370d6dbf609e6b121075b3b999
|
|
DrawGradient should check to see if the polygon is a rectangle before
adding the gradient to the metafile. If it's a rectangle, we are
currently unnecessarily adding XGRAD_SEQ_(BEGIN|END) comment records.
Change-Id: I38aef322469f45403ed105d971d7e1d1441ba6a0
|
|
OutputDevice::DrawGradient doesn't check to see if it's meant to be
drawing a grayscale gradient when it adds it into the OutputDevice
metafile. Now fixed.
Change-Id: I83cb5255c01901e33ca1f751e91e8a77292663e6
|
|
Change-Id: I160a760a13c8e5140d6df295a9dffd05cf5e7b81
|
|
The bounding rectangle actually comes from the polygon. Therefore, it's
not needed. Removed from the following functions in OutputDevice, et al
+ ClipAndDrawGradient
+ XORClipAndDrawGradient
+ ClipAndDrawGradientMetafile
Change-Id: I4a87edcddb8895871982f0448854e1c0854124bc
|
|
Change-Id: Ibd42c70edbd8a5ca5eba34bcb92e801c8dc97ba0
|