[gs-bugs] [Bug 690346] many pcl files from the customer test file directory have problems.

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Tue Mar 24 00:41:41 PDT 2009


http://bugs.ghostscript.com/show_bug.cgi?id=690346





------- Additional Comments From henry.stiles at artifex.com  2009-03-24 00:41 -------
I'm looking at this also.  

Upon playback there are at least as many chunks allocated as there are images in
the file.  When playing back the band list an image enumerator is created for
each high level image.  The image enumerators are huge because of the color
index lookups that are statically defined in each image enumerator.  This
results in ialloc giving each image enumerator being allocated in its own chunk.
 It is the same for pcl, pdf or postscript (the pcl file can be converted to pdf
or postscript with the appropriate high level device).

It is interesting the file works fine if high level images are turned off. 
There will always be large image enum allocations with or without high level
images. In the former case, the large enumerator, that gets its own chunk, is
allocated by the reader, in the latter it's the writer.  But only reader
allocations seem to foul up the ialloc allocator.  With high level images the
clist writer does not allocate the cache color index lookup table (fortunately).
 I guess the pattern of allocations could explain why the allocator fails when
the allocations are done in the reader but that's weak and needs more analysis.

Also, the postscript and pdf equivalents of these files don't have performance
problems, I believe the free object method behaves differently when the maximum
limit is reached in pdf and ps because of the presence of a gc, but I haven't
thoroughly analyzed this.  I have not been able to reproduce the performance
problem using NOGC, but I discovered NOGC doesn't really disable everything.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the gs-bugs mailing list