Add visual tests for blendMode() across renderers

[avinxshKD]

Added BlendModeTest covering all 10 blend modes (BLEND, ADD, SUBTRACT, MULTIPLY, SCREEN, DARKEST, LIGHTEST, DIFFERENCE, EXCLUSION, REPLACE) plus one test that switches modes mid-sketch. Using JAVA2D for now since per-renderer baseline support isn't figured out yet. Windows baselines included, all 11 tests pass locally

Closes #1434

[avinxshKD]

Hey @mingness, PR is up

BlendModeTest covers the 10 modes + one that switches mid-sketch to make sure nothing leaks between mode changes. Using JAVA2D, baselines are Windows. Tests green locally.

[catilac]

@Vaivaswat2244 may I ask you to review this one? :)

[Vaivaswat2244]

Hey @avinxshKD, thanks a lot for your work on this.
PR looks good to me. I did leave a comment around adding some clarifying notes in the code — nothing that needs changing before merge, just things that'll make it easier to follow for whoever touches it next. Let us know if you need any help.

[avinxshKD]

Hey @catilac @Vaivaswat2244 added the comments, kept it minimal, just a one-liner on the helper explaining the test scene setup, a note on why BLEND gets called before the actual mode under test (that one was genuinely non-obvious), and a line in testModeSwitch saying what it's checking for. nothing structural changed

lmk if any changes needed

[avinxshKD]

Hey @catilac once I have my GSoC proposal ready would you be okay with taking a look at it?

[mingness]

Hi @avinxshKD , thanks for your enthusiasm for participating in GSoC with the Processing Foundation. We're committed to keeping the process open and fair, so I encourage you to participate in the Q&A part of the process, where you will be able to ask questions about the projects and applications in an open forum. We can't really provide one-on-one advice on applications - it creates a conflict of interest situation which in the end would not be good for your application, and we want you to have a fair shot at the spots.

Looking forward to your application!

[Vaivaswat2244]

testModeSwitch is the only test that doesn't go through createBlendTest, meaning its background setup lives in a separate code path.

This is fine for now, but createBlendTest also hardcodes background(128) and noStroke() — so if those defaults ever change, testModeSwitch will silently drift out of sync. Worth either routing it through a shared base or leaving a comment that these need to be kept in step with the createBLendTest

[avinxshKD]

Hey @mingness thanks for the clarification, I wasn’t aware of the one-on-one feedback constraint. My bad
I’ll keep proposal discussion in the public Q&A (Discourse, right?) and also continue contributing where useful in the meantime.
Really appreciate the guidance.