On Mon, Jan 17, 2011 at 13:50, Denis Auroux <aur...@math.berkeley.edu> wrote: > On 01/17/2011 10:33 AM, Andreas Butti wrote: >> So we can render all to an image instead of the screen, and then render >> the image to the screen, I anyway do this now, for performance reasons. > > I agree with you that the way to go with Android is to keep the internal > logic (responding to user operations, data structures, etc.); > change the UI to a native one; and either build with Cairo and GLib > (shouldn't be too hard, those libraries shouldn't have any problematic > further dependencies I can think of) or further abstract so that Cairo > rendering can be replaced by something else on Android. Cairo renders to > an image and either GTK+ on Linux, or something else on Android, maps > the image on screen. > > About rendering to image: just to make sure -- have you optimized this? > (I haven't looked carefully at your code). Libgnomecanvas has a lot of > optimizations based on microtile arrays to refresh only what's needed. I > don't think you need such fancy techniques. But, at least, there are a > few things to consider: > > 1. Depending on zoom level, you might not be able to keep a whole > rendered page in memory. You might not want to anyway -- it'll take > cairo forever to draw an entire page at high zoom level, and waste a lot > of memory. So you should only keep in memory what corresponds to the > view port (or a bit more if you want to make scrolling more efficient). > > 2. When something needs refresh, you should only render the necessary > region or rectangle (as directed by an Expose event you're responding > to, or by where the user has been drawing). You definitely want to > render only a small rectangle, not the whole window or the whole page. > > 3. Each item in the journal has a bounding-box attached to it, if the > bounding-box does not intersect the drawing rectangle then you don't > even want to process the item and ask cairo to draw it. > > (Remember a typical xournal page can have up to 100000 line segments on > it, and we want scrolling, resizing, etc. to be smooth even on low-end > machines -- think low-end netbook, or more specifically, Nokia tablets / > later, Android devices). > > Denis >
I haven't yet look at why, but my port to Maemo (they use GTK+ natively with their Hildon UI) has a pretty slow refresh when scrolling the canvas. Someone from Nokia suggested me to use double buffering, but I thought libgnomecanvas would take care of that already. -- anidel ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
