The customer reports the following: I've another problem with USE_HL_IMAGES disabled (which may be, or not, related to the one reported one month ago for Gresyscale rendering). The command: gs -sDEVICE=tiff24nc -DDOINTERPOLATE -sOutputFile=a.tif -r200 -dNOPAUSE -f $1 -c quit If you execute this command with the standard 8.62 (or 8.61), there's no problem. But if you recompile with USE_HL_IMAGE switched to "false", then gs freezes somewhere. The CPU runs at 100%, and nothing more happens. That's only in RGB, and only with interpolation enabled. With 8.60, that's a little bit different: the base 8.60 freezes in all cases, but my patched version of 8.60 (where I've applied all the various patchs you sent me) works (with USE_HL_IMAGES=true, I mean). I found out that the fix comes from the patch you sent me the 11 october 2007 ("Re: Wrong colors CMYK vs RGB"). In case that helps. ------- I've attached the file in question and verified that gshead (r8825) continues to fail in the same manner as described.
The test file is available as casper:/home/support/689952/standards-rgb-new.pdf
Customer should re-test running other bugs with HL_IMAGES true. Without HL images, MANY MANY rectangles will be generated, causing poor performance.
I've been in contact with the customer he and reports better performance with USE_HL_IMAGES = false. My testing verifies this, though all my times are relatively smaller. Specifically, the attached file generates a 180 megabyte temporary file and takes 2:07 to run with stock gs8.63; with USE_HL_IMAGES = false Ghostscript generates a 52 megabyte temporary file and runs in 1:25. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif -r2880 -dNOPSICC -DDOINTERPOLATE ./P_WithRot.eps I'm assigning this to Alex, who owns images.
Created attachment 4414 [details] P_WithRot.eps
assigned to ray for profiling samples.
I confirm the result from #3 with r9348. 50 vs 180 MB tmp file and half the running time after recompiling with 'USE_HL_IMAGES = false' in gxclimag.c.
At 2880 dpi this was taking too long, so I ran some comparisons at 1200 dpi with a debug build so that I get more detailed info from -Z: about the clist size. The command line I used was: gswin32c -Z: -dEPSCrop -sDEVICE=tiff24nc -o nul: -r1200 -dNOPSICC -DDOINTERPOLATE -dBufferSpace=###### P_WithRot.eps The timings I got were interesting and, I think, explain the clist size and the performance issue. The results were: USE_HL_IMAGES=true nbands clist_size output_start complete BufferSpace=4000000 427 610Mb 121.4 sec 311.0 sec BufferSpace=40000000 43 74Mb 5.8 sec 37.3 sec BufferSpace=120000000 15 35Mb 1.1 sec 22.9 sec USE_HL_IMAGES=false BufferSpace=40000000 43 87Mb 10.8 sec 20.9 sec BufferSpace=4000000 427 92Mb 9.2 sec 19.4 sec What this tells me is that the HL images "hit the wall" when there are a lot of bands. This is a skewed image, and I think the clist image logic is at fault. There is a salient comment in base/gxclimag.c:image_matrix_ok_to_band /* * Since currently we are limited to writing a single subrectangle of the * image for each band, images that are rotated by angles other than * multiples of 90 degrees may wind up writing many copies of the data. * Eventually we will fix this by breaking up the image into multiple * subrectangles, but for now, don't use the high-level approach if it would * cause the data to explode because of this. */ Apparently the test for the 't' factor is too forgiving. This probably should take into account the band height and only enable HL images when the image row would not result in the 'explosion' of data. Assigning to Igor to fix this. In the meantime as a workaround we can let the customer know that increasing the BufferSpace will greatly improve performance and reduce the clist size.
I've emailed the customer as per comment #7.
Since the workaround (-dBufferSpace) addresses the performance issue, changing this to P3 enh, LATER The better calculation of the 't' factor is the enhancement.
Changing customer bugs that have been resolved more than a year ago to closed.