Am 17.01.2011 19:50, schrieb Denis Auroux: > 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). I always keep at least the current page in memory, not depending on the zoom level, we have enough memory on current PCs...
(this will take about width * height * 4 bytes...) > > 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. I redraw the whole buffered image, because it's to much work to only render a part of the image, but then I render only the changed part to the screen. (I redraw the image only if change something, if you e.g. draw a stroke the old image is rendered, and the new stroke on top, al long as you are drawing) It is possible to optimize this also, so we only redraw the part of the image which is necessary, but this is a high risk to do error, so I didn't to this for now. On my PC it is enough fast, but we can optimize this a little... > > 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. As I wrote before, If there is a change on the page I redraw the whole image. I hand problems rendering PDF background, there are some artefacts, but I think I know now how to do this... I will do this later... > > (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). Scrolling is no problem, because we have only to render the new part from image to screen. I save the time when you last display a page (e.g you are searching something and you scroll forward and backward) so I don't delete the view buffer, if you don't show the page for a longer time (30s or so, I don't know what I defined) I free the image. I tested this with fast scrolling, I never get more than 100MB used with my version of Xournal. I opened the same Xournal file, with PDF background wit the orignal Xournal version, scrolled fast to the end it used more than 250MByte RAM! (If I scroll slow, e.g. read a document, my version needs about 40MB RAM!) So I think for the moment I think this is OK... I can save about 20MB if I delete all not needed pages, but the scrolling is better if you have a little bigger cache, and 20MB is nothing... Andreas > > Denis > ------------------------------------------------------------------------------ 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
