В Пнд, 07/01/2008 в 23:39 +0100, Reinier Heeres пишет: > Hi everyone, > > 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 > http://dev.laptop.org/git?p=users/rwh/evince;a=summary. Normal > 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! :-) First of all great news really, I'm glad Evince code helps OLPC and actually I suppose it would be nice to merge python bindings. About memory, as I've mentioned the first step in my opinion would be in changing the pixbuf cache to work with arbitrary page chunks instead of the whole page at once. We can discuss it more on irc if you are interested.
Attachment:
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=