View Single Post
Old 11-17-2011, 10:00 AM   #5
hawhill
Wizard
hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.hawhill ought to be getting tired of karma fortunes by now.
 
hawhill's Avatar
 
Posts: 1,180
Karma: 2116649
Join Date: Nov 2010
Location: Goettingen, Germany
Device: Kindle Paperwhite, Kobo Mini
Well, a lot of its speed it currently gains from a simple caching strategy. It will always render the next page just after displaying the current one.

I think starting on zooming and navigation will be the next thing I'll tackle. I will have to revise the caching mechanism and policy for that, I think. Also I'd like to include support for muPDFs "bbox" device that will calculate a "real usage" dependent bounding box for a given page which would allow for cut-to-content feature (the efficiency of which would depend on how the PDF is created, though).

Note that I just added an "emulator" mode that will use SDL for rendering/input, so development on a typical linux PC is possible. This allows for rapid prototyping.

Don't feel pressed to start on this. It's still a "pet project" for me, I'm doing it just for the joy of doing it. BTW, dpavlin already had a look at it and played with it. Github is a great help for integration work, so if you start playing with it, I suggest to just clone the Github repo.
hawhill is offline   Reply With Quote