all three addressed places hit frequently now during "make check", likely
related to recent changes to timer/idle code?

Change-Id: I75963c707807c29db7865b11f9ed532b779765d8

Change-Id: Id657299322ddefb095a2f192df818a873498e411
Reviewed-on: https://gerrit.libreoffice.org/14825Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I5d9734f302ff58637f69c1574bc39ca85ff992e7

Regression from b1534edf (tdf#89592
Using initializer_lists to populate Sequence<PropertyValue>,
2015-03-07).

Additionally, avoid makeAny() on the Any, the original code didn't do
that.

Thanks to lgodard/sberg for noticing these.

Change-Id: Icb3a6039885c582ba9f789c5c4768b865b593aee

Change-Id: I85993df91bd14966f9175c356966fbd8eb1a927d

since 44337a1f "Unit tests for PDF import"

Change-Id: I6c7746814af669dd0eb45b1013577cacc109a014

Change-Id: Idef9dd55eb1719eaf592bc4a86440cbd5aa4fb32
Reviewed-on: https://gerrit.libreoffice.org/14781Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I2b21a488a7f597603b65fac0ff3c6b05c3660994

"... OpenCL on CPU"

I can't reproduce the problem any more. It was likely fixed by
fa4ce83f.

This reverts commit 219f2dc8.

Change-Id: Ib6d3a42137bcf21b0edec2173cf483ade6104b0b

Change-Id: I2d56b0ddf0b7e076ea570879b0ab33390306f3b2

Change-Id: If7351b2fb37b68ea2838cf442ca440a01587d66a

Change-Id: I4d8d0ee853e93c8620295e0598de358e66b4f730

after commit 924b2923
"V801: Decreased performance"

Change-Id: I32af1195f6e7e1fc4b94487bfbfab669bcad3951

Change-Id: I9e8d5863c31187b373ff93d5a6e992a1281220b4

Change-Id: Ic45e42d5ce7e0509cd2afc8be018f78cd6083aae

The TokenPool::operator[] is used to initialise and take into use an object
from the pool. Which is a fascinating thing as such and probably not entirely
in good style. Anyway, the objects in the pool are of type ScTokenArray, a
class derived from FormulaTokenArray. The operator[] called the
FormulaTokenArray::Clear() function to initialise the object. This left the
fields added in ScTokenArray uninitialised, having whatever value the previous
use of the object had set. Which of course is bad.

In practice, this showed up in the handling of formulas in the .xls input
filter. If an earlier (or the first?) formula had happened to be one for which
we don't want to use OpenCL, the meVectorState of its ScTokenArray object in
the pool had been set to FormulaVectorDisabled. When the same pool object was
later re-used for another formula, it kept that same meVectorState, even if
there was no reason to. Thus formula groups that should have been OpenCL
accelerated weren't. This can have a significant impact on performance of
document loading and recalculation for large documents.

I added a function to ScTokenArray to clear (initialise) such an object, both
the FormulaTokenArray part and the ScTokenArray-specific part, and call that
instead. This fixes the issue.

I named the added function ClearScTokenArray() to make it clear that it is a
separate function. Sure, possibly Clear() should be made into a virtual of
FormulaTokenArry and overridden in ScTokenArray, and the overriding Clear()
would first call the base class's Clear(). But I can't be sure that there
aren't other calls of FormulaTokenArray::Clear() that *must* mean the base
class one. Better safe than sorry.

And of course, I did *not* want to name the function in ScTokenArray also
"Clear()", like in the base class, without it being virtual. That is horrible
style in my opinion, even if there certainly is precedence for such even in
the very same classes, i.e. the Clone() function...

Change-Id: I0e0e13e5ca705603005a1e0a46866f095cd2ac4d

Change-Id: I07400d6dead66ec437436b5ea8b49491f8048335

Change-Id: I1e141632172f53ddbd2f5f434206646c9a1e9cf0

introduced in commit d22519f6
"V801: Decreased performance"

Change-Id: Ie8e1e00db91b0d1874abc6a3e6399ff30484f993

Change-Id: I84d997997100af4e21eafc5b458ff98d99c7dbbd

Change-Id: I6a888b58668ccb64c5a9c3270d06c3b9bcf8ce64

Change-Id: Ia076670e7356c378c6e8feb5970033638d2ba0b7

Change-Id: Iaf203682e6d3b18d8b25c6ee2755710615fe5f08

Change-Id: I006b17efd78334c71c0dddbeb6f906cb955a3f39

Change-Id: Ia050a9a0fe5219964ba4d1460260e07fc4ab4fbb

There are use cases when it is useful to disable animations (using
LO in remote display when the bandwidth is limited). This adds an
option that will allow to disable all animations. Currently only
animation when copying cells in Calc (dashed border overlay) uses
this option.

Change-Id: Ia8cd3783140428e921c3151c2f462d3862440edd

Change-Id: Iee31413c1ded4fbda8227e88d09a1f917f18ca5d

Change-Id: Ibd4364f7d30f098df49537c6a6a01915bfa31b8d

Change-Id: I71632990601bfc21ae2e6ba5c640f1dd3e6c1ee5

Change-Id: I4c479f0581e5fde7c3c2c21dcb2a88a2039e09ba

Change-Id: I425005534b9b73c3450112fd9a30035985cc38e1

Change-Id: Id884a4c90c24b38a1dd22a41d271dcc551b59adc

Change-Id: I4052c6f1e5dde71ce4cede1ec9a313f461861d71

Change-Id: Ie9d303a7200cf2a6bfd8c0f5f547cfffccaa0444

There does not appear to be a good reason why searchBackward()
needs to call transliterate() on the entire passed string, so don't do that,
as in the previous commit for the other direction.

Change-Id: Iadfca806da89bf8825e5a3df7fcad64ea08d7f9c

There does not appear to be a good reason why searchForward() needs to
call transliterate() on the entire passed string.

Restricting it to the passed range speeds it up from 104 billion to 0.19
billion callgrind cycles when built with GCC 4.9.2 -m32 -Os.

Change-Id: I440f16c34f38659b64f1eb60c50f0e414e3dfee8

Change-Id: Id8cd45d2844c121f63684734ab3546c24a1aab32