[gs-bugs] [Bug 689944] Reference to free object

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Tue Jul 15 07:29:09 PDT 2008


------- Additional Comments From marcos.woehrmann at artifex.com  2008-07-15 07:29 -------
I've double checked and comment #4 is correct regarding the revision.  I agree
the log message isn't that long, but is longer than most:

r8585 | leonardo | 2008-03-03 08:01:12 -0800 (Mon, 03 Mar 2008) | 79 lines

Fix (clist) : Crop transparencsy commands while clist writing, step 3.


This really crops transparency compositor commands with bands 
that are covered by the transparency bbox.

Actually the statement above has one exception. When a transparency bbox
covers more that 2/3 of all bands, we still write the commands to 
the "all bands" list for a shorter clist file. We noticed that 
the clist playback time strongly depends on the file size.

1. The new method gs_composite_type_procs_t::get_cropping
replies what bands are covered by the compositor. 
When it gives a non-trivial result, clist_create_compositor
writes the compositor command to those bands,
which are covered with the cropping (Exception :
if too many bands are covered, it writes the command to
the "for all bands" list).

2. Since some bands skip some compositor commands,
while clist reading the association of masks to groups 
becomes more complex. Before this patch each group
was associates with the mask, which was created immediately
before it at same transparency stack level. 
After this patch some groups may be skipped, so that
clist reader may recieve extra masks, because masks are
still use the container's group bbox. For skipping such extra masks
we provide a numeric identifier of a mask, which is named mask_id.
Here is how it works :

2.1. All masks recieve serial numbers (mask_id) while clist writing.
2.2. Each mask command is written with its mask_id.
2.3. Each group command is writen with mask_id, 
     which belongs to the mask that is assocuated with the group.
2.4. While clist playback pdf14_pop_transparency_group checks whether
     the mask amd the group have same mask_id. If not, the mask is extra
     and it must be droped.
2.5. Note the old assiciation logic is still working,
     and it may skip some masks as well.
2.6. If the rasterization happens with no clist, mask_id is always zero.
     In this case the old logics is only working.
     Maybe we'll provide non-zero values someday.
2.7. See comments in code for more details.

3. The method gs_composite_type_procs_t::clist_compositor_write_update
is now some generalized. Before this patch it only updates the clist writer state
with the compositor features. With this patch it also adds 
some information from the clist writer state to the compositor parameters.
Particularly it provides mask_id to the compositor command.
Thus now it updates *both* clist writer and the compositor parameters
to comply each another. For a while, in order to simplify the patch,
the compositor argument is still 'const'. Will need to fix someday.

4. Now we need to save mask_id in a stack that reflects the
transparency nesting. The cropping stack, which was introduced
in the last patch, now works for that. To provide that
we add mask_id to clist_writer_cropping_buffer_s,
and use clist_writer_push_no_cropping to save amsk_id
over inner groups. 

5. state_update(ctm) in c_pdf14trans_clist_write_update is replaced
with code, which updates CTM from the transparency compositor command.
The old code is not fully correct, because it takes CTM from the imager state,
rather we havn't got prcatical cases when it gives a wrong result.

6. drop_compositor_queue now calls adjust_ctm for compositors being dropped.
The old code is incorrect because it can miss a CTM update when 
a compositor sets some CTM and later a non-compositor object
sets same CTM. In this case the clist writer skips the second CTM on writing,
and skipping the first in the clist reader will miss the CTM completely.
We haven't got practical cases for that.

7. Improved some debug printing.




------- 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