Reduce XOR rendering Background: Back in the stone age, a fast way to do masking was to XOR render a rectangular texture onto the screen, then draw a shape on it in black; then re-XOR render the texture rectangle - thus removing it everywhere except where the shape was drawn: bingo, a filled shape. Unfortunately, this works really very poorly on modern graphics hardware, cannot be anti-aliased etc. So - it would be great to go through the code (search ROP_XOR) and re-work code portions to render an alpha mask, that can be rendered with instead - for eg. complex gradient cases etc. Some ROP_XOR invocations are still needed for legacy meta-files though, avoid poking them. In some cases these have already been special cased for Mac (no XOR mode), which should mostly be a matter of simply using the Mac conditional everywhere. Skills: C++, graphics etc
Deteted "Easyhack" from summary
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Krisztian Pinter committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=06db1edf617b537d774f487e0ab7d3528c5626df fdo#38844 Remove XOR rendering code from canvas module The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I've made a change to vcl/source/gdi/outdev4.cxx around gradient clipping: http://cgit.freedesktop.org/libreoffice/core/commit/?id=8659d189ec04aca78c8ffff97fcca507ca0a9ec3 I check have seperated out XOR clipping for gradients into ClipAndDrawGradient and XORClipAndDrawGradient. Possibly we can mark the XORClipAndDrawGradient as deprecated and remove it eventually. I did this change without knowing about this bug, btw :-)
Chris Sherlock committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb5c7d6a79309236d4f19bb2498f2e850f735a2f fdo#38844 Reduce XOR clipping for gradients The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Is this EasyHack resolved and fixed?
(In reply to Stefan Weiberg from comment #6) > Is this EasyHack resolved and fixed? please answer
Read what the initial comment says. "search ROP_XOR". Do you find any?
I don't know. I'm not a developer and I don't understand anything about the code. I just wondered if the work was done in this area or if it's still a work in progress easy hack just like tehe "remove genrman comments" thing
There are still ROP_XORs in the code, so I would assume this is not fixed.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillCpp ) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
i want to work on this
A polite ping, still working on this bug ?
(In reply to jan iversen from comment #14) > A polite ping, still working on this bug ? yes
Another polite ping, @charan, still working on it?
I am assigned to this bug but I have no idea about the source code. Can anyone help me with the bug details and master code?
A polite ping, still working on this bug?
Dear Ashis Paul, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Hello, I did a search with grep -ri ROP_XOR . and got no hit. See the original ticket description (https://bugs.documentfoundation.org/show_bug.cgi?id=38844#c0).
(In reply to oo.o+libreoffice from comment #32) > Hello, > > I did a search with > grep -ri ROP_XOR . > and got no hit. > See the original ticket description > (https://bugs.documentfoundation.org/show_bug.cgi?id=38844#c0). That's because ROP_XOR was changed to RasterOp::Xor The issue is definitely not resolved yet... unfortunately.
Re-evaluating the EasyHack in 2022 This enhancement is still relevant. Searching for RasterOp::Xor gives several (38) results.
I would like to work on this issue.
Re-evaluating the EasyHack in 2022 This enhancement is still relevant. I revised the searching for RasterOp::Xor, excluding those related to emf/wmf, and workbenches. It's around 21 instances, mostly in vcl: $ git grep RasterOp::Xor|grep -v wmf|grep -v emf|grep -v workben drawinglayer/source/processor2d/vclhelperbufferdevice.cxx: // copy RasterOp (e.g. may be RasterOp::Xor on destination) drawinglayer/source/processor2d/vclhelperbufferdevice.cxx: // during painting the buffer, disable evtl. set RasterOp (may be RasterOp::Xor) drawinglayer/source/processor2d/vclpixelprocessor2d.cxx: mpOutputDevice->SetRasterOp(RasterOp::Xor); svx/source/xoutdev/_xoutbmp.cxx: pVDev->SetRasterOp( RasterOp::Xor ); sw/source/uibase/utlui/shdwcrsr.cxx: m_pWin->GetOutDev()->SetRasterOp( RasterOp::Xor ); vcl/backendtest/outputdevice/outputdevice.cxx: mpVirtualDevice->SetRasterOp(RasterOp::Xor); vcl/backendtest/outputdevice/outputdevice.cxx: mpVirtualDevice->SetRasterOp(RasterOp::Xor); vcl/backendtest/outputdevice/outputdevice.cxx: mpVirtualDevice->SetRasterOp(RasterOp::Xor); vcl/qa/cppunit/outdev.cxx: CPPUNIT_ASSERT_EQUAL_MESSAGE("Not an XOR rasterop", RasterOp::Xor, vcl/qa/cppunit/outdev.cxx: CPPUNIT_ASSERT_EQUAL_MESSAGE("Not an XOR rasterop", RasterOp::Xor, vcl/qa/cppunit/svm/svmtest.cxx: pVirtualDev->SetRasterOp(RasterOp::Xor); vcl/source/filter/imet/ios2met.cxx: case 0x04: return RasterOp::Xor; vcl/source/filter/imet/ios2met.cxx: case 0x0b: return RasterOp::Xor; vcl/source/filter/ipict/ipict.cxx: case 2: eActROP=RasterOp::Xor; break; // Xor vcl/source/filter/ipict/ipict.cxx: case 6: eActROP=RasterOp::Xor; break; // notXor vcl/source/filter/svm/SvmConverter.cxx: eRasterOp = RasterOp::Xor; vcl/source/gdi/mtfxmldump.cxx: case RasterOp::Xor: return "xor"; vcl/source/gdi/print.cxx: mpGraphics->SetXORMode( (RasterOp::Invert == meRasterOp) || (RasterOp::Xor == meRasterOp), RasterOp::Invert == meRasterOp ); vcl/source/gdi/virdev.cxx: mpGraphics->SetXORMode( (RasterOp::Invert == meRasterOp) || (RasterOp::Xor == meRasterOp), RasterOp::Invert == meRasterOp ); vcl/source/outdev/gradient.cxx: SetRasterOp( RasterOp::Xor ); vcl/source/outdev/gradient.cxx: SetRasterOp( RasterOp::Xor ); vcl/source/outdev/outdev.cxx: mpGraphics->SetXORMode( (RasterOp::Invert == meRasterOp) || (RasterOp::Xor == meRasterOp), RasterOp::Invert == meRasterOp ); vcl/source/window/window.cxx: mpGraphics->SetXORMode( (RasterOp::Invert == meRasterOp) || (RasterOp::Xor == meRasterOp), RasterOp::Invert == meRasterOp ); There are several other instances that may not be directly related, but worth taking a look: $ git grep XOR *.cxx|wc -l 237
Multi-hack, not assigned.
(In reply to Hossein from comment #36) > $ git grep RasterOp::Xor|grep -v wmf|grep -v emf|grep -v workben > vcl/source/gdi/print.cxx: mpGraphics->SetXORMode( (RasterOp::Invert > == meRasterOp) || (RasterOp::Xor == meRasterOp), RasterOp::Invert == > meRasterOp ); In this one it sets the XOR mode on the acquired graphics object based on the current raster operation (meRasterOp). So, can we replace the SetXORMode() function with SetCompositionMode() to transition away from XOR rendering in the Skia backend? got some idea after searching - https://cpp.hotexamples.com/examples/-/QPainter/setCompositionMode/cpp-qpainter-setcompositionmode-method-examples.html Or is there any other way?
Hey I've released a patch here: https://gerrit.libreoffice.org/c/core/+/180137 Can you please let me know if I am headed in the right direction.
Raising difficulty per recent discussion. When working on this, it is crucial to test your changes in LibreOffice itself. Surprising issues may arise.
Removing easy hack bits as the remaining work is too complex.