| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the event that we encounter an allocation failure for the rectangle list
in a complex clip path, we'd previously leave the point set to NULL, which
worked well for Postscript where processing would stop on such an error.
With PDF, we have to try to carry on, meaning we'd later try to dereference
that NULL pointer.
So, in that event, put the old rectangle list back (and return the error code).
This reflects what happens for regular paths.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A gx_clip_path holds 2 possible representations of a clipping region.
Firstly, it will hold a list of rectangles that exactly cover the given
clipping region. Every gx_clip_path will hold such a list, though
in many cases it's a singleton.
Secondly, it may hold a gx_path pointer to point to the path that
can be used to regenerate the clipping list. In order for this
regeneration to happen correctly, we really need to know the
fill_adjust value that was in place when the path was added to the
clipping region.
This last piece of information was not kept by gx_clip_path - this
commit rectifies that.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function does not, currently, appear to be called from anywhere.
For the new PDF interpreter we'd like to use it to copy the clip path(s)
from the PostScript environment to the PDF environment, but there's a
problem.
The problem is that the structures defining the list of rectangles are
allocated using the same memory allocator as the source clip path, but
when we come to free them, the destructor uses the memory allocator of
the clip list. So if the destination clip path was using a different
allocator from the source clip path, we will use the wrong allocator to
try and free the memory.
Chris thinks this may be an attempt to cope with stack-based allocations
of the clip path where the allocator is NULL. So to cope with that
we use the existing code (allocator from the source clip path) if the
destination clip path's allocator is NULL (stack based) and we use the
destination clip path's allocator otherwise.
|
| |
|
|
|
|
|
|
|
| |
Prevent memory leaks by propagating error codes and freeing loose objects.
Also resolve some compiler warnings.
Error created using :-
MEMENTO_FAILAT=19484 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5efts/fts.0051
|
| | |
|
| |
|
|
|
|
| |
Introduce a PRI_INTPTR and use that to consistently display
pointers. We avoid using %p, as that displays inconsistently
between platforms. Sometimes it does 0x%x, sometimes just %x.
|
| |
|
|
|
|
|
| |
Update functionality to propagate error codes correctly and release path segments.
Error created using :-
MEMENTO_FAILAT=15840 ./membin/gpcl6 -sDEVICE=pbmraw -o /dev/null ./tests_private/pcl/pcl5cfts/fts.1552
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
gx_cpath_unshare() does not copy the clip path list, and leaves the list
structure uninitialized.
Until/Unless we implement copying the list, set the values in the list to
zero/NULL so later freeing of the unshared clip path doesn't trip up.
|
| |
|
|
|
|
|
|
| |
Fix memory leak when pcl_mark_page_for_current_pos returns an error code.
Also prevent path becoming orphaned in cpath_set_rectangle.
Error created using :-
MEMENTO_FAILAT=9010 ./membin/gpcl6 -sDEVICE=ppmraw -o /dev/null ./pcl/examples/owl.pcl
|
| |
|
|
|
|
|
|
|
| |
Also update copyright dates.
Remove gs_cmdl.ps as we no longer use it, and remove its entry from
psfiles.htm.
Remove xfonts.htm as this feature (xfont support) is long, long gone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug # 698005 "regression: commit 70cfc6afc42b9c299e9c05359f12455055105fac with Bug692720.pdf"
Commit 70cfc6 created a path from a list of rectangles early in a clip,
in order to minimise the number of times the path was created (creating
it later caused it to be discarded and re-created multiple times)
Unfortunately, as I feared at the time, this introduced a memory leak
under certain conditions. When the clip_path is discarded we weren't
counting down the reference to the path_list.
With this commit Bug697270.pdf uses approximately the same amount of
memory as it did before commit 70cfc6, but runs approximately 20%
faster.
The regular cluster run also seems to exhibit a further ~20% improvement
in performance, presumably in addition to the existing 10% from the initial
commit. Note, this *only* affects configurations where the clist is
used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ghostscript clip paths consist of 3 parts:
1) A list of scan converted rectangles that union together to give
the clipping region.
2) (Optionally) a path that represents the clipping region.
3) A path_list structure (a list of paths that when intersected
together give the required clipping region).
3 is required for high level devices like pdfwrite (and the opvp
device).
Most of the code is at pains to preserve path_list as gx_cpaths are
manipulated. The exception to this appears to be the clist code.
The rectangle list is sent through the clist, but the path is not.
Accordingly, the code to intersect a gx_cpath with another path
checks to see if the path_list is valid on entry. If not, it
synthesizes one from the rectangle list.
This bug is caused by the fact that we end up intersecting a
clip path 120000 times in a pattern clist playback. Each of those
synthesizes a path from the rectangle list.
The fix here is to make the pattern clist playback create the
path_list each time it is replayed, meaning we have < 100 such
operations.
Thanks to Ken for his work on this, and for coming up with the
initial version of this patch.
|
| |
|
|
|
| |
Not really expecting any huge speed benefit from this, but
it's silly to call it twice with the same args.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we create a clipping device from a path, we copy over the
pointers to the rectangle list, and start searching them from
the start.
This means that if we perform an operation that causes lots of
calls to something with the same clipping path (like for instance
a stroke operation with a clipping path that calls down to a fill
path with a clipping path), then we will repeatedly search from
the top of the rectangle list.
This massively slows stuff down.
This commit introduces a 'cached' entry in the clipping path
that can be updated after a clipping device has been used to show
the last place in the list that was found. Subsequent creations
start searching from this point.
This gives us the desired locality of reference, and massively
speeds up the test file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the clip list accumulator is optimized for x-major entry of rects,
if we know the information is y-major, as for landscape imagemasks, then
transpose X and Y in the list, and similarly transpose back when doing
the clip_enumeration bounds checking and calling the target operation
(process function).
This improves the processing of the customer's file from 1900 seconds to
96 seconds!
So far only landscape imagemask clip path accumulation uses this. TBD
is to evaluate if any other uses of the clip path accum device can take
advantage of this transposition.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change how gstate initialisation is done:
Previously we relied on the imager state being a subset of the gstate (thus
assigning an imager state to a graphics state over wrote to the entries
common to both, and didn't overwrite any already set graphics state specific
entries).
Making the imager and graphics states the same means that approach doesn't work,
so this changes it to initialise the entries individually.
Renames gsistate.c->gsgstate.c and gxistate.h->gxgstate.h
Cleanup and fix the gs_state gc stuff.
Uses different check for pre/post clist pdf14 device
Previously, the code used "is_gstate" in the imager/graphics state object
to determine if the code was being called pre or post clist (post clist would
only ever have had an imager_state so is_gstate = false).
With no imager state any more, that test would no longer work (and I am dubious
about whether it was really safe, anyway). Other places check for the presence
of a clist reader device in the pdf14 device structure - so use that here
too.
Adds initial (NULL) value for show_gstate pointer in gs_state.
Removes the now pointless macro for the contents of the graphics state
Changes function names that had "imager" to use "gstate"
Removes the redundant 'is_state' flag
Cleans up gs_(g)state_putdeviceparams():
Previously we had to similar routines: one took a graphics state, and used the
device from the graphics state, the other took an imager state and the device
as an explicit parameter.
With the removal of the imager state, "merge" those two functions
Replaces gs_state with gs_gstate
It makes for less confusion as it really is a g(raphics)state
|
| | |
|
|
|
Squashed into one commit (see branch for details of the evolution of the
branch).
This brings gpcl6 and gxps into the Ghostscript build system, and a shared
set of graphics library object files for all the interpreters.
Also, brings the same configuration options to the pcl and xps products as we
have for Ghostscript.
|
