Evince and OLPC
- From: Reinier Heeres <reinier heeres eu>
- To: evince-list gnome org
- Subject: Evince and OLPC
- Date: Mon, 07 Jan 2008 23:39:45 +0100
I'm new to the list and working as an intern for OLPC, who are
developing the $100 laptop. The XO (as the machine is called) will
probably be used as an e-book reader extensively. The software running
on this laptop has a completely redesigned UI with a focus on
collaboration and being understandable for young kids. To make
everything fit together we had to create a new PDF reader for this UI.
Of course we didn't want to write it from scratch, so we decided to base
it on Evince.
Our application uses an evince View (ev_view) object embedded in a
python application. This turns out to be fairly easy to do, with only a
few modifications to the source tree to support building a library
suited for embedding, and generating python bindings. I cloned the
evince svn tree into a git tree available at
compilation should still be possible, so maybe it would be nice to merge
this embedding support back into the main tree in the (near) future: it
might be useful for others, and of couse for us it would be much easier
to follow the main tree.
Our hardware is very resource limited: the laptop has 256MB of RAM and
no swap, since there is only 1GB of flash memory and you don't want to
swap to that. The embedded evince eats quite some memory, especially for
files with (large) images. I found bug
http://bugzilla.gnome.org/show_bug.cgi?id=504913, which discusses the
fact that extra gtk.Images are created for right-click -> copy actions.
We don't support this feature, and disabling it resulted in about 3
times less memory usage for the pdf I linked to in that bug. I think for
an embedded evince this should probably be default behavior, at least
until a fix is available that creates those images only when they are
required. But maybe a configure option would be nice for that for the
time being; I'll probably implement it like that in our git tree.
Anyway, this is not the main reason for my post. As I said, memory is
scarce in our system. We are being bitten a bit by the fact that evince
renders the whole page, and not just the visible part. The screen on the
XO is pretty small and high-res, so people will sometimes want to
zoom-in quite a bit, resulting in high memory consumption. I've seen in
the roadmap at http://live.gnome.org/Evince/Roadmap that this is a
future feature for which resources are not really available. Bug
http://bugzilla.gnome.org/show_bug.cgi?id=303365 discusses the issue as
well. This is probably not that easy to do, and I wonder what you guys
think about the solution.
For us it's pretty high priority, and I have a bit of time to work on
it. Suggestions on how to start implementing and perhaps some help
actually doing it would be greatly appreciated; I don't know the
code-base that well. I want to make sure that if I work on this, I do it
in a way that there is a good chance of it going upstream as well since
I think it would be a good improvement to evince.
Beside this issue, evince works perfectly for us! :-)
] [Thread Prev