Things get slower once you load a ton of objects into the canvas -- it's bound to happen given that a page of handwritten notes typically consists of about 100,000 line segments, and if there's a PDF background then PDF rendering itself is also a CPU-intensive beast.
Three comments: 1. the code mostly relies on gnomecanvas' ability to optimize things, which works to a large extent but not on extreme situations with lots of pages (however in my experience the slowdowns start more around 50 pages than 15). Apparently goocanvas for GTK3 is less optimized and, as indicated by Daniel, more optimizations are needed either in goocanvas or in the xournal-gtk3 code. Arguably, even the original xournal code could benefit from some optimizations; I felt that performance was acceptable-ish enough on typical use cases for this to not be a high priority. 2. one way to make the interface refresh a lot faster and decrease CPU and GPU usage (but not gaining any significant RAM savings if memory consumption is your issue) is to use View -> One Page instead of continuous mode. Then you have to change pages manually instead of having continuous scrolling, but the workload for gnomecanvas is greatly diminished since the inactive pages are not rendered. 3. chaining files: yes. "cat file1.xoj file2.xoj > file3.xoj" produces a valid xoj file if file1 and file2 are "pure" xoj i.e. do not annotate a PDF background -- or even if just one of them has a PDF. If both have a PDF background, then you need to remove the reference to the PDF file on the first page of file2.xoj before combining the files since the format only allows one reference to a pdf filename in the whole .xoj file. (Or you could patch the file loading code to just ignore extraneous pdf filenames instead of rejecting the xoj file). Operations like extracting a subset of pages and recombining pages between xoj files should all be easy to write as scripts for command-line manipulation -- just gunzip the .xoj file, manipulate the XML <page>...</page> sections as desired, and voila. (or perhaps re-gzip at the end if you don't want your file sizes to become unreasonably large; xournal doesn't care whether the file is compressed or not, but always compresses them upon saving). Best, Denis On 11/20/2013 02:10 PM, Shuhao Wu wrote: > I get pretty bad performance after about 14 pages of notes. Adding a > page, loading and everything gets really slow. > > Can we mitigate this somehow? I noticed that .xoj files are compressed > files (?), can we chain these files together so the performance doesn't > degrade? > > Shuhao > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Xournal-devel mailing list > Xournal-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xournal-devel > -- Denis Auroux aur...@math.berkeley.edu University of California, Berkeley Tel: 510-642-4367 Department of Mathematics Fax: 510-642-8204 817 Evans Hall # 3840 Berkeley, CA 94720-3840 ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
