summaryrefslogtreecommitdiffstats
path: root/android
diff options
context:
space:
mode:
authorTor Lillqvist <tlillqvist@suse.com>2012-06-21 17:01:34 +0300
committerTor Lillqvist <tlillqvist@suse.com>2012-06-25 09:12:11 +0300
commitcd43461697c0532b5056f9d3449e880d88084c7d (patch)
treedbd519b03eeee969e70c5f33931d01cb3f53c450 /android
parentBin accidentally committed file (diff)
downloadcore-cd43461697c0532b5056f9d3449e880d88084c7d.tar.gz
core-cd43461697c0532b5056f9d3449e880d88084c7d.zip
Add some "thinking aloud" style comments
Change-Id: Ib4a57649ec98bcbce851687633f35e52771f137a
Diffstat (limited to 'android')
-rw-r--r--android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java37
1 files changed, 32 insertions, 5 deletions
diff --git a/android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java b/android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java
index 50e8a0669b26..ec3855f012f5 100644
--- a/android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java
+++ b/android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java
@@ -17,15 +17,42 @@
// - rendering a page (render())
// Unclear whether pages can be rendered in parallel. Probably best to
-// serialize all the above in the same worker thread, for instance using
-// AsyncTask.SERIAL_EXECUTOR.
+// serialize all the above in the same worker thread. We use
+// AsyncTask.SERIAL_EXECUTOR below.
// While a page is loading ideally should display some animated spinner (but
// for now just a static "please wait" text).
-// Just three views are used for the pages: For the current page being viewed,
-// the previous, and the next. This could be bumped higher, need to make the
-// "3" into a parameter below.
+// ===
+
+// How should we handle re-rendering at higher resolution when zooming in, and
+// then panning around?
+
+// Hopefully when LO is asked to render just a part of a page (i.e. the
+// MapMode of the device rendered to causes significant parts of the page to
+// be outside the device) the code is clever enough to quickly skip stuff that
+// will be clipped. But I don't hold my breath.
+
+// How could we do it?
+
+// 1/ Re-render just the zoomed-in area. Probably not a good idea, as probably
+// the user will almost immediately also pan a bit or zoom out a bit, which
+// would cause a re-render.
+
+// 2/ Some kind of tiled approach. Initially just one tile for the whole
+// page. When zooming in, at some point (2x?) split the currently visible
+// tiles into four sub-tiles, each initially displaying the same resolution as
+// the parent tile. Start asynchronous rendering of visible sub-tiles at
+// double resolution. Keep the "parent" rendered bitmap but don't keep bitmaps
+// that go out of view. (Except perhaps for some caching.) When zooming out,
+// at some point (0.5x?) merge four sub-tiles back into one. Hmm. Is this the
+// right approach?
+
+// In any case, also this rendering at higher resolution should be done
+// asynchronously, of course. If the user zooms in and pans around, the
+// existing bitmap will be shown scaled (and ugly) until required rendering
+// has finished and then the affected tiles are replaced with
+// higher-resolution ones.
package org.libreoffice.android.examples;