Split out from bug 690585 comment 9. Obviously pclxl_strip_copy_rop() was left incomplete because there is room for optmization for some combination of input values via PXL ROP3's, but it has not been done for the last 15 years. gx_default_* should be called, but ideally some additional optimization could be done. After attachment 8598 [details] is applied, there should be some changes in the cluster tests, in the form of *progressions* (since the patch is "obviously" correct). The list of postscript/pdf files showing progressions (as well as those 17 pcl files) should be recorded here as possible candidates for optimization.
The two files in bug 692853 also use this code path and are possible candidates for optimization.
Like I said in Bug 693054 Comment #3 the patch is not good. It will cause any files that use the destination to fail - not just render incorrectly but end prematurely. Your patch could be changed to factor the Destination out of the "lop" parameter and then call gx_default_strip_copy_rop(). The complete solution is to set the raster and transparency operations in the XL output using the driver calls, then create an XL image from the source parameter and an XL pattern from the texture parameter. Also the color would need to be set appropriately. Lots of hand waving here, I'm sure there is much to trip over.
(In reply to comment #2) > Like I said in Bug 693054 Comment #3 the patch is not good. It will cause any > files that use the destination to fail - not just render incorrectly but end > prematurely. Your patch could be changed to factor the Destination out of the > "lop" parameter and then call gx_default_strip_copy_rop(). > > The complete solution is to set the raster and transparency operations in the > XL output using the driver calls, then create an XL image from the source > parameter and an XL pattern from the texture parameter. Also the color would > need to be set appropriately. Lots of hand waving here, I'm sure there is much > to trip over. There is a way of fixing both this (to some extent) and bug 693054 for the case of pxl simultaneously, by essentially creating an optimized rop path for those two files, thus by-passing gx_default *for pxl*. But this combination does not solve the problem of pswrite's use of gx_default*. In any case, both of these issues (this, from something that works to something that works better, or the other, that gx_default isn't completely useable as the default) are outside the original pxl bug, I think.
The primary candidate for optimization is 0xfc(TSo) followed by 0xff(1). These two are used by most frequently, by the files listed in 690585#c9 and the two files in 692853 . The 4 files which aren't fixed by 690585#c12, uses these: pcl5cftsfts.2105 0x1(DTSoon) 0x2(DTSona) 0x3(TSon) 0x4(SDTona) 0x5(DTon) 0x6(TDSxnon) 0x7(TDSaon) 0x8(SDTnaa) 0x9(TDSxon) pcl5cftsfts.2114 0x35(STDSxnox) 0x4c(SDTana) 0x63(SDTnox) 0x7a(DTSDnoax) 0x91(SDTSnoaxn) fts.0980 0x11(DSon) 0x2f(TSDnoan) 0x60(TDSxa) 0x71(SSDxTDxaxn) 0x80(DTSaa) 0xa0(DTa) 0xe3(TSDT aoxn) 0xf5(TDno) fts.0982 0x3c(TSx) 0x48(SDTxa) 0xbe(DTSxo) 0xe9(DST DSan axxn ) So that's 27 (+2, "TSo" and "1") as candidates. Out of the 27, 24 involves the destination. This is just a rough list, as Henry correctly suggested in comment 2, implementing any of these the way it should, modifies the internal lop state of the core, and pclxl_strip_copy_rop() may not be invoked in the same way next time, so the list will change as some of this list are optimised.
We probably won't get to this soon so marking: LATER