With this, the tiles get rendered correctly at varying zoom levels.

Change-Id: Id5ca18e363dfdb143af1685be96af2f3c3514ea9

ScRangeList::DeleteArea() may remove an entire range, if it was the
last range a subsequent call to ScConditionalFormat::DeleteArea() would
attempt to access an invalid first element.

Change-Id: I8d68c27963dc8561d61a94980093c271bd3aaffb

This could save a million iterations ...

Change-Id: I44fb228b951580bbeb5df5f6ec7be933077776ff

This works well at 100% zoom, but the offsets are still not correct
at zoom levels other than 100%.

Change-Id: I301362b00ca916410b69f39aa58ed871ce177d88

Change-Id: I344efb9ea71d5eccdfb6255526db912622d115df

...as e.g. the read+write+exec arena used in
bridges/source/cpp_uno/shared/vtablefactory.cxx has specific requirements on
obtained memory.  This broke recent 8b9968a2
"fdo#72755: Only use double mmap as fallback" for e.g. --enable-ooenv (which
sets G_SLICE).  This is a partial revert of
ce906b80 "skip tricky allocators on
G_SLICE=always-malloc."

Change-Id: I5a5fb7c3c920a7856381e6c55638137c625b5111

Change-Id: I0deee2c3cfdb111b178c4254d7b0544c4ce5c966

Change-Id: Ib226d7ec13bc64ee6d32fab3c3f6cecc4eb8b151

Change-Id: I79371b4ad9d29a5ab8fd01244c3f80db92b07f97

...when write+exec mmap fails (due to SELinux deny_execmem).  This avoids the
tmp file creation in environments that don't need it and which in turn have
problems of their own with that tmp file business.

An alternative would be to first check whether SELinux deny_execmem is enforced
and only then try double mmap first.  An advantage could be that it might avoid
false SELinux alerts in that case.  The disadvantage would be the overhead of
introducing a conditional dependency on libselinux here.  And given that for one
deny_execmem typically appears to be off by default (as at least both
contemporary GNOME desktop and OpenJDK malfunction when it is enabled), and for
another I guess deny_execmem could still change its value between the time of
checking for it and the time of requesting a write+exec mmap, that just does not
seem worth it.

Change-Id: I3560803139b630557b6219d3db52945c7e0cdcd2

So that the callback code running on the main thread can be aware of the
event type and payload (necessary in the future to do partial repaints).

Change-Id: I790b2ce0b6f9f88ba71d94a17bf0c8fc1b567c5f

Change-Id: Id0a93f1c4199082b3c67802955082d04831ec124

Change-Id: I29acea58b4e18efcf33b51361812c3f7532282ab

Change-Id: I77372ae2b1c7c4332dc4a8c244c67a82f9551e22

Change-Id: I5e9598249457c62d3ccc9c5f754526c1fbe969bf

Change-Id: I306fbe12e0a91e28bb2308074ded03b768173440

Change-Id: I7b3acba83de0c17bd4723fb6623827dbbb82fbbf

With this, gtktiledviewer gets the proper invalidation rectangles after
keypresses.

Change-Id: I9bd1f5b59d05ae93a0a1d018dda8b2efc01cb38c

Change-Id: I3a98358934b79a2ace574714aa331fdce4a421bb

When the invalidation callback is invoked, we call PaintTile() for each
tile that is affected by the invalidated rectangle. Make sure
PaintTile() doesn't result in new invalidations generated by itself,
to avoid infinite loops.

Change-Id: I593726bd7e72028f26103829831949f000665e95

Change-Id: I9b40a32e08f4472b75a236e2720ecbe5927117fb

Change-Id: I54c5fbe0b24ecf82de2d3d9f72d7f72d59125d58

Change-Id: Iaf8339f1cadc4f77dfefb1e268126745d6ed7eaa

Change-Id: I6134d434ca34c0f3e839a3d78b67c5cefff53a48

Change-Id: I9c85aa5de1495e16ec67f68043784c661c2b66ab

Change-Id: If42dc9487fe11e2950becaf6b9ec857496dc6669

Change-Id: I684c7af245cc755b94f69e175c652d161e0f643a

Change-Id: I9612b0d5258bbdef81903b3a67307fe54319e9c1

Change-Id: Icc0c749a0c8687f247c4e42d74b5c839d5723503

Change-Id: I2df86c2837fc6469384df5626a2d54856e96f8e7

Change-Id: Ie4b3e48d3f06545ebfd8638cdb8e4664ad85f493

Change-Id: I0fedb5bb353e4d6f9926a8c0f0b80a81b7257d0e

Change-Id: I937eac9e613695490c8617aac85575f5e6fe290b

Change-Id: I2d7ee76e132856483cdfa8f89641725c26762e37

Change-Id: I246965ac341ef0deeb30f1d3a0c518e67a074869

The primary purpose of gtktiledviewer is to see the same features / bugs
than on mobile devices. On Android we already render 256x256px tiles, do
the same in gtktiledviewer instead of a single huge tile.

Change-Id: I377dcab59e7019dcf1d15a27ccba117eb53d0d5b

Change-Id: I7ee58b2c889da3ca01969617f7a382bf4135b7a1

As pointed out by JunitTest_sw_unoapi.

Change-Id: Ia553dfb48215fab44f4899223c63ee454ff1c648

The size of the root frame is usually the max of the page frame widths,
except when the visual area is larger, in which case the root frame is
the visual area width, and page frames are centered (when there is a
single column).

When doing tiled rendering, we are not interested in the gray area
around the pages (not more than just having a gap between pages), so
never do this centering. This has two benefits:

1) When painting the tiles, we change the visual area already to always
have the given tile visible, that would undo this centering anyway, but
changing the size of the root frame causes a pointless
mass-invalidation.

2) When getting the size of the document, this way the width of the
document (root frame) will independent from the visual area, i.e. it'll
be always the same.

Change-Id: Ib0d86bbe6c7b5a83646264a2f308624179ad6982

Change-Id: I6a1f8bb8fd04e40ecd60eec87043e507ca6350e7