[OpenJDK 2D-Dev] [9] request for review: 8036022: D3D: rendering with XOR composite causes InternalError.

[Jim Graham]

Hi Andrew,

It looks like you are covering the case of the existing loops being 
Solid and we switch to XOR so you get new loops.  What about the case 
where we used to be XOR and then we switch to Solid and the loops might 
be stale, but in the other way (i.e. XOR when we want Solid rather than 
Solid when we want XOR)?  Also, if we were XOR and we remain XOR, does 
this force us to fetch the loops on every validate?

I forget the strategy for the loops variable, was it supposed to be set 
to null to force a refetch somewhere, but some invalidation case missed 
setting the loops=null for XOR?

		...jim

On 3/13/14 4:54 AM, Andrew Brygin wrote:
> Hello,
>
> could you please review a fix for CR 8036022?
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8036022
> Webrev: http://cr.openjdk.java.net/~bae/8036022/9/webrev.00/
>
> In case of XOR composite, rendering pipeline falls back from
> d3d to gdi. However, gdi surface data does not re-set rendering
> loops during validation, that leads to usage of the software
> loops (due to dst type mismatch), and results in observed internal
> error.
>
> Suggested fix forces the re-set of the rendering loops,
> at least for the case of XOR composite.
> This change does not trigger any existing regression test.
>
> Supplied regression test demonstrates the problem.
>
> Please take a look.
>
> Thanks,
> Andrew.