Improving image anti-aliasing performance?

[ral...@webdox.cl]

Hello,

We are using pdfium in our in-house electron PDF viewer. At the moment, we generate bitmaps of pages and encode them as PNG, we then add a hidden text layer on top by using the text rects.

Latency of rendering (generating the bitmap) and image size increases 2x when using image antialiasing. We've seen anti-aliased examples with lower latency and size within Google Drive (provided they use pdfium) and Chromium.

To avoid performance issues, we are currently rendering without anti-aliasing using options FPDF_RENDER_NO_SMOOTHIMAGE | FPDF_PRINTING.

Is there any other setting or option we could use to improve anti-aliasing performance?

Kind regards,

[Lei Zhang]

What's the main concern? Speed or image size?

Is your code using FPDF_RenderPageBitmap()? PDFium's pdfium_test
binary also uses FPDF_RenderPageBitmap(). Can you compare the
performance of your application vs pdfium_test and see if there are
any significant differences?

I can't speak for Google Drive. Chromium's PDF Viewer uses different
rendering functions from public/fpdf_progressive.h, and it does not do
PNG encoding.

> --
> You received this message because you are subscribed to the Google Groups
> "pdfium" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pdfium+un...@googlegroups.com.
> To post to this group, send email to pdf...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pdfium/133c9a92-980f-4c99-813c-05cccc521545%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[ral...@webdox.cl]

Thank you Lei,

The main concern is the right balance between speed and image size. Doing antialiasing now increases both latency and size ~2x, but we've seen examples with good anti-aliasing at lower latency and size.

We are using FPDF_RenderPageBitmap(). Could we do progressive rendering at 4 threads (top left, top right, bottom left and bottom right page quadrants?) to improve speed?

The size probably increases at PNG encoding because I understand there's no options or flags for the stretching engine used with image antialiasing?

Kind regards

[Lei Zhang]

Who is doing the PNG encoding here? It's not PDFium, right?

PDFium is single threaded. Progressive rendering just pauses the
rendering and gives control back to the caller periodically. It
doesn't make rendering faster. You can certainly try rendering parts
of a page in different processes, and stitch them together at the end.
That would be interesting, but it is up to you to see if that is the
right solution for your needs.

With anti-aliasing, the rendered image has more variation in color.
That's harder to compress, so the PNG will definitely be bigger. I
don't think there's a way around that. AFAIK, with PNGs, there are
optimizers that can try to shrink them, but they are fairly slow.

> https://groups.google.com/d/msgid/pdfium/f10bbe21-62b4-427e-89ae-10acdb879669%40googlegroups.com.

[ral...@webdox.cl]

We are using libpng and the image_diff_png impl in Chromium.

There's no way to tune the antialiasing engine parameters?

[Lei Zhang]

For anti-aliasing, we use FreeType, so if you look in the PDFium
source for "FXFT_RENDER_MODE" and see how that's set. There's probably
more options there than what is available with the public APIs. If you
want to experiment with that. Changing the anti-aliasing mode may
speed things up, but produce hard to read text.

For Chromium's PDF Viewer, the way it uses
FPDF_RenderPageBitmap_Start() is to only render what is visible. So in
some cases, it may be able to perform faster because it is rendering
fewer pixels.

So you have looked into how much time is spent rendering PDFs vs.
encoding them with libpng? I think if you profile your application's
performance, you can get a clearer picture of where the time is spent
and figure out what to do.

> https://groups.google.com/d/msgid/pdfium/5135eb31-1f56-4823-add5-ae2eff7cc824%40googlegroups.com.