[poppler] Default Qt frontend image formats

Albert Astals Cid aacid at kde.org
Thu Aug 27 13:55:38 PDT 2015


El Diumenge, 16 d'agost de 2015, a les 21:34:56, Adam Reichold va escriure:
> Hello,
> 
> we recently changed the default image format produced by the Qt frontend
> to RGB888 since that is improves rendering speed within Splash and
> yields a smaller QImage (and hence less copying for the Qt4 frontend).
> 
> However, doing some heap profiling, I noticed that this change should
> probably be reverted since this implies a conversion and hence at least
> one additional copy when converting the resulting QImage to a QPixmap
> with most Qt platforms, especially with Xcb using the Raster pixmap
> implementation. The increase in maximum working set size this yields
> will surely compensate any memory size savings of using RGB888 images as
> a source.
> 
> Also, what we gain in speed during rendering, we would probably loose to
> some degree even when painting these RGB888 images directly, since Qt's
> Raster paint engine has no optimized blending functions for RGB888.
> 
> The previous default format of ARGB32 was also suboptimal in this
> regards, since it would still imply that QRasterPlatformPixmap detaches
> from the QImage's data yielding an additional copy on which it would
> just change the format from ARGB32 to RGB32 after explicitly checking
> that it was actually given opaque data.
> 
> Hence I think the correct choice is RGB32 for opaque pixel data since
> this has optimized blending functions and QRasterPlatformPixmap will
> neither convert nor copy this as it will usually coincide with the
> screens native format (as per QNativeImage::systemFormat).
> 
> For IgnorePaperColor, the same can be achieved by choosing
> ARGB32_Premultiplied instead of ARGB32 which will also not be copied or
> converted by the Raster pixmap implementation.
> 
> Attached is a patch that makes those two changes yielding significant
> reductions in maximum working set size. Also note that while the
> premultiplication does have a performance impact, it slows down the
> IgnorePaperColor path by less than one percent w.r.t. the default path.
> 
> Best regards, Adam.

Pushed

Cheers,
  Albert


More information about the poppler mailing list