Bug 691891 - Potential bug in transparent ROP operations
Summary: Potential bug in transparent ROP operations
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: master
Hardware: All All
: P4 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-17 11:15 UTC by Robin Watts
Modified: 2011-01-17 11:19 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Watts 2011-01-17 11:15:17 UTC
When performing rop operations in gdevmr8n.c, we can optionally have the S or T planes transparent.

The current code implements this as meaning that if either S or T is set to have transparency enabled, then S or T being the highest color index possible on entry (0xFF in 8 bit modes, 0xFFFFFF in 24 bit modes) will be treated as being transparent. This means that the result of the rop is assumed to be transparent too.

For certain values of rop, however, the input values of S or T may be ignored; it seems unlikely that S being 0xFF should cause the output of the rop to be transparent when all other possible values of S are ignored.

This should be tested, and (if there is indeed a problem) it should be fixed.
Comment 1 Robin Watts 2011-01-17 11:19:47 UTC
Actually, on closer examination of the source, it looks like we're safe.

 if (!rop3_uses_S(rop))
     const_source = 0;

So in the event that S is ignored, we can never match the transparent index anyway.