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

[Albert Astals Cid]

Moreover patterns on PDF are VERY slow, have a look at 
http://bugs.kde.org/show_bug.cgi?id=99486 in xpdf (kpdf dies because second 
page takes AGES).

In xpdf you can see pages 1, 3, 4, 5, 7, 8 and 9 without problems. Rendering 
page 6 takes 1 minute to render in my system due to the graphic hacing a 
pattern, i've never been able to finish the rendering of page 2. The problem 
is for each small pattern piece it parses all the commands from the pdf and 
then executes them. I've been have to reuse the parsing and get it down to 40 
seconds but it is still too much. What should we done is render the pattern 
once and then repeat the drawing all over the place, but i have not been able 
of finding how to do it. If someone achieves this it can be a good reasont to 
go on with the commonxpdf library at freedesktop.

Albert

A Dissabte 19 Febrer 2005 13:40, Enrico Ros va escriure:
> 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=m
>arkup (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
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel