Now done in TiledLibreOffice's lo_initialize(), but should probably be
done in common LO code instead.
Change-Id: I398a703943d13c6d715e4c88ead2a629955fb7c9
When the environment variable DRAW_INCREMENTALLY_FROM is set to a
number, we want TiledLibreOffice to loop, initially performing only
that number of drawing operations in AquaSalGraphics, then wait for
some seconds, and redraw. Next time perform one operation
more. Repeat.
Implemented in vcl by surrounding the entry and exit(s) of the drawing
functions in AquaSalGraphics with macros.
All this is active only for iOS and in a dbgutil build.
CATiledLayer does not guarantee that tiles are drawn in the same order
each time so using a "tile number" for DRAW_ONLY_TILE was not
perfect. Use tile coordinates instead when wanting to restrict to
showing just one tile.
Change-Id: I23f4a3ecaf47cd3392d2d950bd279260b3a7b9f4
Useful for debugging. Also, make the tile border drawing
optional. These three debugging features are governed by environment
variales (set in Xcode before running with Alt+Product>Run...)
DRAW_ONLY_TILE, DRAW_TILE_BORDERS and DRAW_TILE_NUMBERS.
Change-Id: I81f952284676eafe5d204c819658e0225aabdb1c
Make it easier to handle several test docs. Until now you had to
change the hardcoded document in the Xcode project and in the lo.mm
source file and re-build. Now it is enough to upload a new test doc to
the device using iTunes. If no test docs are present, use the good old
bundled test1.odt.
Change-Id: I3cbb9f74c17332ffc6ac90dd1e226fac005c3387
The executable of the LibreOffice app (which as such at the moment
doesn't work, since the tiled rendering changes) is built using
gbuild, and thus we can't generate the native-code snippet in the
CustomTarget that builds the app bundle, but need it already when
building the executable. This is one wayt to handle that.
Change-Id: Ifdab40c970e93b1f2608cefc637df8a8e5396efe
This allows us to get rid of component-declarations.h and
simplify component-mapping.h.
For new, converted, implementation_getFactories, adding one line into
native-code.py should be enough to make them available in application.
Change-Id: I042320e5b7f8a9aa9f02b77d2bdd07cf9a690ee6
Avoid an implicit upper limit on the value calculated (and displayed) by
keeping a counter, too, for each slot in the array.
Also edit a comment, as I now have a better understanding of how the
tiling works.
Change-Id: I5df4076917a244f73f27b66f4983f17ce95b9df7
Running dsymutil takes much too long to be bearable during
development. But when building for actual release we do want a
separate dSYM of course. (Of course none of the current iOS apps in
the source are intended to be actually "released". But add this logic
just for completeness.)
Change-Id: Ibb5037d6926e969a891269d6c9d86232bc01cb3c
No one says this is the only good classification.
Quite possibly it's not even a good one, but at least something.
Change-Id: I81178314222f9f63708a83b262ff8ef73a1d9467
...to directly call constructor functions of ComponentContext-based C++
implementations of (non-single-instance) UNO services. The case where these
calls would need to be bridged across different environments (e.g., from gcc3
to gcc3:affine) is not yet implemented.
bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
concept (which had previously been adapted to use the prefix="direct" feature,
which may become unnecessary again in the end, depending on how to handle
single-instance services/singletons). More to follow.
Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
I had to add some horrible hacks to make sure the test doc has been
loaded into a Writer shell before retrieving its size and being able
to render it. Obviously some better solution is needed. But this is
just a testbed to get some profiling data.
The app is built using an Xcode project, and in gbuild through a
custom target based on the MobileLibreOffice one. Setting up the
various files used (or not used...) at run-time should really be
factored out from the CustomTarget files.
Change-Id: I1711b0cae9d28a09b73476b2d37d98b1820c9943
It's not terribly nice, but, hopefully, better.
The hope is that one day, lo_get_library_map will be no more.
In lo_get_implementation_map we can specify more precisely what to link
into the binary.
Change-Id: I99a1854fbae05be2f70302cc56bea88e522ec129
