[Libreoffice-commits] .: android/experimental

[Tor Lillqvist]

 android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java |   37 ++++++++--
 1 file changed, 32 insertions(+), 5 deletions(-)

New commits:
commit cd43461697c0532b5056f9d3449e880d88084c7d
Author: Tor Lillqvist <tlillqvist at suse.com>
Date:   Thu Jun 21 17:01:34 2012 +0300

    Add some "thinking aloud" style comments
    
    Change-Id: Ib4a57649ec98bcbce851687633f35e52771f137a

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 50e8a06..ec3855f 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;