[Kde-graphics-devel] KPdf evolution [Mosfet hint wanted]

[Enrico Ros]

On Sunday 13 February 2005 19:24, Zack Rusin wrote:
> On Sunday 13 February 2005 12:56, Enrico Ros wrote:
> > - How can be a new generation EBOOK reader ... ??
> 
> 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.
> [ ... ]
> So essentially, I think that before tackling the really cool features we
> could focus on performance. 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?

Finally I'm back from uni and I can post my considerations to the list.
Definitely this is an issue. KPdf overhead over xpdf is less than 5-10% on 
mean cases, but when rendering images xpdf has some overkill bottlenecks!

-- problems details:
Btw you are totally right, I have a testcase that takes ages for 
rendering [1]. This is mainly because of poor (well, maybe it's the opposite 
case) rescaling stuff -> here are my first impressions:
- slow image downscaling: a 1500x2000 px image (pretty normal on 'scanned
   pdfs' or ones with graphical background) rendered to a 50x75 rectangle
   takes every pixel processed and manipulated.
   -> 3M operations (actually function calls) in such a case!
- drawPixel calls: Splash (the rendering class) has lots of memory buffer
   types, even if we (as kpdf) want 32bits only color pixels.
   drawPixel does its best to waste cpu (from 90% to 10% of the total 
   time, depending on when the 'slow downscaling' problem tops that).
- bad image upscaling: image is not smoothscaled up.. it's a block
   scaling! like a QImage.scale().. (not,maybe worst) looks bad.

-- current state:
The scaling algorithm is something like a traversal to the DESTINATION 
image (scaled/transoformed) but every pixel in the SOURCE image is 
processed using a Bresenham like transform.. so:
-downscaling: every pixel on screen is the mean average of a 1 or many 
pixel region in the source image. (on the other hand Downscaled images 
looks better in xpdf than in acrobat reader)
-upscaling: a pixel in the source image is mapped to one or more pixels on 
screen. (looks 'blocky')

-- the balance (IMO!):
-preserve some quality for downscaling (acrobat one can be enough)
-smooth in upscaling (linear iterpolation is way cooler than 'blocks'). note 
that upscaling speed of acroread is similar and it doesn't interpolate too!

-- notes on the scaling algorithm [2] and implementation:
- image scaling must be 1) clipped 2) transformed (using available 
   parameters).
- I think Mosfet is probably the best guy in the whole planet to ask 
   for the fastest transformed image scaling. He can change the rendering
   speed by orders of magnitude I think.
- We already have a wrapper function in place so we 'might' optimize worst
   (and well defined) cases and let the other ones flow through the 
   current code.
- The 'Splash' renderer supports many types of buffer formats (as said 
   before). contraining its implementation to the 32 bits one will allow 
   to remove many 'if's and 'case's and definitely speed up drawPixel.

References:
[1]: slow pdf
http://robotics.dei.unipd.it/~koral/KDE/PhysRevB.26.4199.pdf
[2]: rescaling stuff can be found on
http://webcvs.kde.org/kdegraphics/kpdf/xpdf/splash/Splash.cc?rev=1.3&view=markup
(Splash::drawPixel and Splash::drawImage methods)

Thanks for your work and all inputs,
Enrico
--
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Novità per telefonare risparmiando: Email.it Phone Card, clicca e scopri i vantaggi
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2689&d=19-2