> Is this performance dependence just a feature of the implementation which one > can’t get around, or are there solutions to improve the performance?
I forwarded question to Jens and got this answer: First, you must restrict the zoom factor to avoid a number overflow. If the monitor resolution is 96 DPI then the zoom factor must be restricted to 64. The real zoom factor is then 64 + 96 / 72 = 85.33. The zoom factor must be further restricted if the monitor resolution is higher since the rasterizer uses 24/8 bits fixed integer coordinates. The current implementation is generally not designed to render tiles. A tile renderer depends on a cached content stream and it requires another clipping technique to avoid gaps between tiles. RenderPage() must decompress and parse the entire content stream over and over again for every tile. This is inefficient and wastes a lot of processing time. However, a tile renderer will be available soon (probably within the next six weeks). Maybe you wait just a few weeks until the new tile renderer is available. Greetings Christian -- Read our blog about news on our plugins: http://www.mbsplugins.de/ _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list mbsplugins@monkeybreadsoftware.info https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
