Bug 692632

Summary:	clist logic wastes BufferSpace when doing transparency.
Product:	Ghostscript	Reporter:	Ray Johnston <ray.johnston>
Component:	Graphics Library	Assignee:	Ray Johnston <ray.johnston>
Status:	RESOLVED WONTFIX
Severity:	enhancement
Priority:	P4
Version:	master
Hardware:	All
OS:	All
Customer:		Word Size:	---

Description Ray Johnston 2011-10-27 03:37:57 UTC

The band_height calculation divides up the BufferSpace into n bands, but when
the page has transparency, the band_height is reduced to try and keep the
pdf14 transparency buffers within the BufferSpace, but since the buffers are
not allocated from the printer device's 'base' memory (BufferSpace size), the
space in the base memory past the reduced band_height is just wasted.

Probably we should free and re-allocate the BufferSpace to the size needed for
the reduced band_height during rendering, then free and reallocate the original
size again after rendering the page. At least this would keep to total RAM
needed closer to what was intended with the BufferSpace parameter and the
pdf14 clist implementation.

This could be a critical issue in an embedded implementation.

Comment 1 Ray Johnston 2018-07-25 21:19:11 UTC

Also, in page mode, we should defer allocating the device's page buffer until
the PDF14_POP_DEVICE does its put_image since it won't be written into until
we use pdf14_put_image to "blit" the pdf14 device's top page buffer into
the device buffer. This allows the transparency stack to be allocated when
there is no full page device buffer, reducing the RAM high water mark.

Also, in page mode, we don't need to clear (fillpage) the device's page buffer
since it will be written ENTIRELY from the pdf14 top page buffer.