Monthly report for July

[Vaivaswat2244]

Added the monthly report.
Please have a look @mingness @SableRaf

[Stefterv]

Hi @Vaivaswat2244 and @mingness,

Thanks for the report. As I was reading through it, I’d like to get a better overview of the proposed system. Could you please clarify which parts of the current p5.js visual testing codebase can be reused, and which parts could be shared between p5.js and Processing?

A key part of this project is finding the right balance between the added complexity of integrating the two systems and the potential benefits of sharing future development efforts.

[Vaivaswat2244]

Hello @Stefterv ,

How This Thing Would Actually Work:

So the basic idea is pretty straightforward - we've got one central comparison engine that both Processing and p5.js can talk to, but through their own "translators" (adapters). Think of it like having a really good image comparison service that both platforms can use, but each one speaks to it in their own language.

The Architecture (Keep It Simple):

The beauty here is that we're not trying to force Processing to work like p5.js or vice versa. Each keeps doing what it's already doing - p5.js keeps using Vitest, Processing keeps using Gradle. But when they need to compare images, they both use the same underlying engine.

What We Can Actually Share:

The Big One - Core Comparison Engine:

Essentailly the part that will be reused will be the comparison algorithm which is working in p5 right now

The comparison engine will be an npm package consisting of this algorithm. The package will then interact with the processing and p5 repositories in certain manner
The engine will include

• The pixelmatch algorithm that p5.js already uses.
• All the threshold logic and "is this different enough to care about?" decisions
• The actual image diffing and highlighting stuff
• The smarts around managing false positives

What We're Reusing from p5.js:
Honestly, most of the hard work is already done in p5.js. We're basically taking:

• The proven pixelmatch setup
• The threshold management that already works
• The visual reporting system (not merged yet but thinking of applying something like this for reporting) Adding Visual Test Report in Github Actions p5.js#7653
• The general approach to handling CI integration

The Adapter Strategy:
Instead of trying to merge everything into one giant system, we write thin wrappers:

Java adapter: Handles Processing's world ,using the gradle-npm plugin
JavaScript adapter: Works with p5.js's existing Vitest setup

This way, if p5.js wants to change how their tests work, they can do that without breaking Processing. And vice versa. The shared engine just sits there doing image comparisons and doesn't care about the ecosystem drama.
The whole point is to get the benefits of shared development (bug fixes, improvements, consistency) without the headache of trying to make two very different ecosystems play nice together at a deep level.

[Stefterv]

Thank you @Vaivaswat2244 for this further clarification, that is very helpful!

Could I suggest focusing on the Processing test infrastructure first, before the shared comparison engine? Strengthening the testing infrastructure for Processing is likely to have a greater immediate impact.

[mingness]

Hello @Stefterv , we definitely are focusing on developing testing infrastructure for Processing before p5. Part of that infrastructure is the js code that can be reused, and then there will be the java-based testing infrastructure. All of this is the next step that Vaivaswat is developing.

[Stefterv]

Okay, my suggestion would be to first build the testing infrastructure with a simplified comparison function and after that build the comparison engine in Javascript that can be re-used by both p5 and Processing.

[mingness]

It looks great - just a bit high level, as if the target audience was your boss's boss - in future reports, think of your target audience as a colleague, and put more detailed information about your work and thoughts and decisions. No need to change this report further than my suggested edits; just change the tone in future reports. 👍

[mingness]

btw, these changes are not required before Vaivaswat can get paid. changing to approve.

[SableRaf]

btw, these changes are not required before Vaivaswat can get paid. changing to approve.

Hi @mingness. On second thought, I realized tying the stipend to the merging of the report puts too much pressure on the review process. Take your time. There’s no rush to merge. We will have a proper evaluation at the mid-point.

[Vaivaswat2244]

Hello @SableRaf @mingness @Stefterv
I've made the changes which were requested. Kindly go ahead and have a look and if anything needs to be changed, let me know.

[mingness]

Thanks, it looks great.