Bug 358782 - BIRT postscript emitter improperly sends cached images for non-reused content which can cause out of memory or insufficient memory error in postscript interpreter on long reports.
Summary: BIRT postscript emitter improperly sends cached images for non-reused content...
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Birt-ReportEngine-inbox@eclipse.org CLA
QA Contact: Hao Zhou CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-23 17:49 EDT by nolan.letellier CLA
Modified: 2011-11-09 21:21 EST (History)
1 user (show)

See Also:


Attachments
proposed replacement for postscript emitter header.ps file. (3.92 KB, application/postscript)
2011-09-23 17:57 EDT, nolan.letellier CLA
no flags Details
A postscript emitter generated file demonstrating images that are not reused (321.89 KB, application/postscript)
2011-09-23 18:15 EDT, nolan.letellier CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description nolan.letellier CLA 2011-09-23 17:49:34 EDT
Build Identifier: M20110210-1200

Some report items (images, flash charts and ...?) are generated as cached content by the drawimage() method in the postscript emitter java source.  This causes them to be stored in the postscript interpreter's memory in case they are needed again for subsequent pages.  When this cached image path is used for non-reused content, that content must remain in the postscript interpreter's memory until the end of the postscript job.  This memory consumption can cause the postscript interpreter to run out of memory on longer jobs with many images / charts / drawings, etc.  The exact point at which the postscript interpreter runs out of memory is a factor of the report content and the specific postscript interpreter (printer model, browser plugin, etc).  This has been observed in reports as short as 60 pages, and is a serious issue for 400+ page reports with graphic content.  

A cached image from the BIRT postscript emitter is easily identified by the fact that it is rendered with a postscript procedure named drawimage, where an uncached image is rendered with a postscript procedure named drawstreamimage. 

There are several things that could be done to solve this problem, or to reduce the frequency or likelihood of encountering it.  

Improvement #1: change /drawimage and /endDefImage to keep the cached image compressed in memory rather than uncompressed image.  This is particularly effective for business charts and vector graphics but less effective for photographs.  (see modified file header.ps to be attached to this report)

Potential improvement #2: only use the cached image path for images that are *actually* reused in the report.  Scan the report to see if a specific image is used more than once, and then output it as cached or uncached as appropriate.

Potential improvement #3: provide an option for the postscript emitter to disable cached images in the output.  For reports that hit this problem, disabling cached images should allow the job to process with substantially reduced memory requirements.

Fix idea #4 (probably doesn't meet other needs): simply remove the cached image path from the postscript emitter and output all images as uncached images.

Reproducible: Always

Steps to Reproduce:
Use the report design from Actuate flash integration demo pack. available online at http://demo.birt-exchange.org/landing/index.php

Do a postscript export of the report. 

(Unfortunately, I am not able / not allowed to provide the rptdesign for a report that produces this problem with only the opensource BIRT)
Comment 1 nolan.letellier CLA 2011-09-23 17:57:01 EDT
Created attachment 203944 [details]
proposed replacement for postscript emitter header.ps file.

This is a proposed change to the header.ps file (from 2.6.2 BIRT postscript emitter) which simply leaves cached images in compressed form in postscript interpreter's memory until the image is actually rendered onto the page by drawimage operation.  This will reduce memory consumption due to cached images.  (for business graphics, a substantial reduction, for photo images, much less)

As noted in the bugzilla report, there are many other ways to address this issue.
Comment 2 nolan.letellier CLA 2011-09-23 18:15:51 EDT
Created attachment 203945 [details]
A postscript emitter generated file demonstrating images that are not reused

Note in the attached postscript file that the images /image0, /image1, /image4, and /image5 are def'ed as postscript variables and there is no action taken to free the memory occupied by them within the context of this postscript job.  If this report were to continue to additional pages, the memory for these images would not be freed.