[Kde-graphics-devel] KPdf evolution

[Albert Astals Cid]

Personally i'd prefer that you tried to improve xpdf code itself, providing a 
even better good reason for the common xpdf lib (as getting code merged 
upstream seems almost impossible)

Albert

On Sunday 13 February 2005 21:49 Zack Rusin wrote:
> On Sunday 13 February 2005 12:56, Enrico Ros wrote:
> > - How can be a new generation EBOOK reader (yes, 'cause kpdf can
> > support many formats, not only pdf, despite of its name) ??
> > - What can a program offer you to help you reading / browsing through
> > your documents ?? { Translation of text, Google-like indexing,
> > Summarizing, Page painting, Animations, OpenGL 3D book-like view,
> > Brain content injectors, Retinal Beamers } ? :-) Maybe something
> > more?
> 
> I love KPdf but there's one thing that bothers me and it's really 
> related to xpdf and it's the rendering speed of any pdf's with images. 
> When it's all text, everything is fine but when you hit an image the 
> drawPixel calls are killing it. An example of a simple presentation is 
> at: http://ktown.kde.org/~zrusin/pbuffers2.pdf. Notice how the cpu jumps 
> to 100% on both startup and scrolling. I usually compile/run simulation 
> on my machine in the background so having a document viewer taking so 
> many cycles.
> So essentially, I think that before tackling the really cool features we 
> could focus on performance. I'm willing to work on that because it's 
> the last thing that bothers me a lot. The big question is how do we 
> want to fix it? Improving the xpdf image rendering can be done by 
> either porting the drawing code to Qt and then optimizing like any 
> other Qt app/lib (which would probably kill the freedesktop xpdf 
> initiative) or trying to simply improve the Xpdf drawing code.
> Opinions?
> 
> 
> Zack