Vectorize GaussianBlur effect.

[jpobst]

I'm not sure what Pinta's policy on AI assisted code is, but one thing it's pretty good at is vectorizing code. I let it rewrite the algorithm in GaussianBlurEffect to use modern .NET's hardware accelerated intrinsics that weren't available 15+ years ago.

The results are pretty impressive on my AMD Ryzen 5900X (PintaBenchmarks):

Method	Mean	Error	StdDev	Allocated
Current GaussianBlurEffect (Radius = 5)	794.88 ms	12.031 ms	11.254 ms	920 B
Current GaussianBlurEffect (Radius = 25)	3,341.77 ms	12.794 ms	11.341 ms	1080 B
Current GaussianBlurEffect (Radius = 45)	5,923.35 ms	39.630 ms	35.131 ms	1240 B
Vectorized GaussianBlurEffect (Radius = 5)	20.81 ms	0.415 ms	0.919 ms	64038820 B
Vectorized GaussianBlurEffect (Radius = 25)	64.29 ms	1.262 ms	1.240 ms	64039722 B
Vectorized GaussianBlurEffect (Radius = 45)	98.91 ms	0.955 ms	0.893 ms	64037248 B

There are 2 tradeoffs:

• Increased memory use - The algorithm uses 16 bytes per pixel while it is running. For example 64 MB for the 2000x2000 test image in PintaBenchmark used above.
• IsTileable = false - The algorithm relies on operating on the entire image at once, so it does not support progressive preview rendering. It simply shows the finished image when it is completely done. Perhaps progressive preview was an artifact of its time and ideally we can be fast enough that it isn't really needed any more. 😉 Other effects that call GaussianBlurEffect were also marked as not Tileable.

AI Summary: Separable Gaussian Blur with SIMD Accumulation

What changed

File: Pinta.Effects/Effects/GaussianBlurEffect.cs — complete rewrite of the Render method

Algorithm change: 2D → Separable 1D + 1D

The old implementation applied the Gaussian kernel as a combined 2D operation using a sliding window. The new implementation decomposes it into two sequential 1D passes:

Horizontal pass — convolves each source row with the 1D kernel, storing Σ w·B, Σ w·G, Σ w·R, Σ w·A per pixel into int[] intermediate arrays
Vertical pass — convolves each intermediate column with the 1D kernel per ROI row, then computes final output

This reduces per-pixel work from O(kernel²) to O(2·kernel), giving a ~100× speedup at radius=100.

SIMD optimization

The vertical pass inner loop uses Vector256 intrinsics to process 8 intermediate values per SIMD iteration (widening from int to long via Vector256.Widen, then multiply-accumulate).

Memory efficiency

Row accumulators use ArrayPool.Shared to avoid per-row heap allocation.

[cameronwhite]

Hey Jonathan!
I don't have any objection in principle with this type of change - it's more the low effort / untested AI pull requests that bother me :)

I'll need to find some time to do a closer review of the changes, but I think the main considerations are maintainability (e.g. perhaps there are some vectorization utilities that could be factored out for other effects) and that extra memory usage requirement.

[pedropaulosuzuki]

Having the Gaussian Blur be separated into two passes (horizontal/vertical) is a huge improvement, even more than the SIMD stuff (which is also very good to have). Even though we probably want to use the GPU to do those calculations in the future, having a fast CPU fallback implementation is a good idea.

About using LLMs, I think it's not a good idea, as all the commercial models are unethically trained on copyrighted data, without respect for Free and Open Source licenses. So even if the code is reviewed and made good, I'd still probably be careful on using LLM generated code, even if it is improved afterwards by human hands, as it still taints the project and people will look at it with bad eyes (myself included). Though, as this MR is from Pinta's original creator, maybe people won't care. Just my two cents.

[pedropaulosuzuki]

Maybe it would be more elegant to use a while loop here, as we're not using the variable declaration expression, which makes it look a bit weird.

while (i < length) {
	// code
	++i;
}

Same for the previous loop, though the increment being on the end might create a small disconnection, due to that loop doing more things.

[cameronwhite]

Happy to hear more input from others in the community on this, since it shouldn't just be my decision :)

The other thing to think about is that if we do add some sort of policy, how would it be enforced? It's easy to detect slop, and possibly more generative cases like this, but it's quite possible for the changes to be indistinguishable from something a contributor could have written themselves.

[Lehonti]

My contributions to this specific project are mostly impact-driven (having powerful and permissively-licensed software tools), not an academic or artistic exercise, so in principle I support any tool that helps get things done correctly and with good quality.

I am not someone to adopt fads, but AI is here to stay, and in the jurisdictions I operate in, there are basically no problems with copyright as long as there is a human in the loop. I sometimes use it for speed, to avoid spending lots of time searching through the documentation and do some of the boring work, and in any case I curate and refine the output, because I want to know exactly what my changes do.

I am not a fan of policies. But if I had to draw a line it would be those pull requests where there is zero or insufficient human oversight. "Insufficient" can be subjective or case-by-case, but if it works I am okay with that.

[yioannides]

Happy to hear more input from others in the community on this, since it shouldn't just be my decision :)

I don't mind LLMs, in the sense that I don't mind automating a. menial tasks (like batch conversion) that b. I'm fully capable of understanding and operating myself, via LLMs that only refers to the source material itself and doesn't infringe on other people's intellectual property.

However, I'm very anti-vibe coding for moral (and environmental) reasons, knowing that all popular LLMs have been illicitly trained on other people's code without any permission like @pedropaulosuzuki wrote and the slippery slope it's creating; start throwing some AI sprinkles here and there, humans taking a backseat over AI in the name of convenience and ending up with a future discussion over 'reclaiming intellectual ownership' of a creative project seeming quaint, as well as AI now referring to its own wasteland of a database, since humans won't be coding anymore (dead internet theory and all that).

I don't care as much about whether we could be using AI on open-source projects because it's not illegal, as I care about whether we should be using AI to begin with. Obviously people can go about it as they wish, it's just my own personal opinion on the matter.

[pedropaulosuzuki]

Adding two references of what I believe are good LLM policies:

GNOME Calendar and LibAdwaita:

This project does not allow contributions generated by large languages models (LLMs) and chatbots.
This ban includes tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these
steps as precaution due to the potential negative influence of AI generated content on quality, as
well as likely copyright violations.
This ban of AI generated content applies to all parts of the projects, including, but not limited
to, code, documentation, issues, and artworks. An exception applies for purely translating texts
for issues and comments to English.
AI tools can be used to answer questions and find information. However, we encourage contributors
to avoid them in favor of using [existing documentation](https://developer.gnome.org/) and our
[chats and forums](https://welcome.gnome.org/). Since AI generated information is frequently
misleading or false, we cannot supply support on anything referencing AI output.

They have a good compromise of allowing the usage of LLMs for translating issue text and comments, which help people who don't speak english and allow them to be able to contribute and speak with everyone else. They also allow using LLMs for studying how things work when the documentation is lacking, which is also acceptable, although they advise against it when possible, as LLMs are unpredictable by nature and can (and possibly will) give false information.

For anything else, using LLMs is not allowed.

The other thing to think about is that if we do add some sort of policy, how would it be enforced? It's easy to detect slop, and possibly more generative cases like this, but it's quite possible for the changes to be indistinguishable from something a contributor could have written themselves.

About this, it's the same as "if people commit a crime and don't report, then we might not know they did it, so it's best to allow them to kill and torture people around, because at least we will know when it happens". If we can't detect something, then we can't detect it, there's not much we can do. But allowing those tools to be used freely is not a good idea, and I'd probably leave the project if "LLM assisted contributions" (except for the exceptions listed above) were accepted.

[pedropaulosuzuki]

As this is blocked at the moment due to the discussion on LLM usage, I made a small refactor on the previous Gaussian Blur implementation (25fee0b) as an exercise, since the original implementation was very messy and hard to read. While doing so, I had a small gain in performance (radius 100 - 6000x4000 image went from 3 minutes to 2 minutes and 40 seconds, also another 3000x3000 image went from 1 minute and 10 seconds to one minute). Nowhere near as impressive as the gains from this PR, as I only did the horizontal/vertical separation, and none of the SIMD/multithreading.

My goal was not to open a PR, as I'm sure that @jpobst would be quick to implement the SIMD/Multithreaded stuff even without LLMs, but I just wanted to throw this here, as the LLM generated code is also a bit messy and hard to read (though more readable than the original implementation), even though it is way, way faster. Also, my rewrite also suffers from not updating live (it could if we did the two passes as two separate filters, which we could do in the future), so it's probably not suitable to merge anyway. My goal was to try to find ways of improving the readability of this code, even more so for the future GPU acceleration of this and other functions. (#2097)

[Lehonti]

I recently landed a gig where I am porting a VB6 codebase to C# using Claude Code, and I am pleasantly surprised with how it's going, so I have a few new insights.

My conclusion so far is that AI coding can work, but it looks different from what we are used to. For example, I think it could work if:

• The coding style is well thought out, very consistent, and with very rigid and compiler-enforced conventions that a human would consider unnecessary and pedantic (for example, getting the build to fail if an instance member comes before a static member). And I recommend a functional programming style. This has to do with how LLMs work; they are statistical machines, so the more consistent the code structure is, the less they have to guess, and the reasoning power gets focused on the domain logic, not the conventions. In this sense, the Pinta codebase has a long way to go, and needs to be refactored.
• Unit tests are an extra guardrail. Coding agents will run tests after each significant change, and if any of the tests fails, they will be forced to see what went wrong. Thorough testing helps.
• Ocassionally, human oversight is necessary. Most often to see if what the agent coded matches your intent. It is also good to review the code itself, but the rigid conventions I mentioned help keep this to the minimum. In my particular case, I will read the final version, after I finish. In the meantime I am (with solid reasons) confident in what it's doing, but I will still check it at the end just to be sure
• The reason that I use AI for coding with confidence is that I can program without AI. AI is not a substitute for software development expertise
• I think AI-coding for a GitHub project is not the same as AI-coding alone. When I am by myself I can make big changes with confidence because I have all the context, but this changes when I am submitting code for someone else to review. I have tried to make my contributions to Pinta bite-sized. However, I think that @cameronwhite (the lead maintainer) could make bigger changes when he is comfortable enough in what he is doing. But again, I think the codebase is not quite there yet. If I were the lead maintainer of Pinta I wouldn't feel 100% comfortable modifying it in its current state.

[cameronwhite]

After giving this some more thought and re-reading the earlier discussion, these are my current thoughts:

• no agents or LLM-generated changes with little oversight.
  • This is pretty self-explanatory since we want to keep code quality as a priority, and everyone seemed in agreement on this
  • Also, I don't really want to spend my time reviewing these types of PRs. It's not fun for me (I'm not being paid to work on Pinta), and this project should be people-driven rather than attempting to maximize development speed at all costs
• supervised LLM usage is more of a gray area which had conflicting opinions in the earlier discussions, since it can definitely be a useful tool when used appropriately
  • copyright is a very valid concern when non-trivial code is being generated, and we should be particularly sensitive to this as an open-source project
  • For tasks that are similar to traditional IDE refactoring tools, the result is likely indistinguishable from what the contributor could have been done without an LLM so I don't think there is much issue aside from moral objections to LLM usage. This type of thing I've left unspecified in the proposal below
  • we can't easily enforce any policy around this by detection. I think our policy would just have to be a checkbox in the PR template like "This PR does not violate the contribution guidelines" so that new contributors hopefully at least look at the policy

The Godot engine recently updated their contribution policy and it ended up being pretty close to my current thinking on this, so I've reused some of their nice wording below:

Proposed policy:

• Code must be authored by a human contributor, and must be compatible with the MIT license and not violate copyright.
  • This implies: no autonomous AI agent use, and no use of AI to generate substantial pieces of code
• No AI-generated text in human-to-human communication
  • When our maintainers volunteer their time to review your issue, PR, or proposal, they do not want to talk to a machine. This is a basic principle of respect.
  • Machine translations are acceptable as long as the original content was written by a human

[zbcoding]

Proposed policy:

• Code must be authored by a human contributor, and must be compatible with the MIT license and not violate copyright.

  • This implies: no autonomous AI agent use, and no use of AI to generate substantial pieces of code

• No AI-generated text in human-to-human communication

  • When our maintainers volunteer their time to review your issue, PR, or proposal, they do not want to talk to a machine. This is a basic principle of respect.
  • Machine translations are acceptable as long as the original content was written by a human

Can you put this in a pull request template? I was looking for this project's AI guidelines.

[cameronwhite]

Can you put this in a pull request template? I was looking for this project's AI guidelines.

I'll do this soon - I was hoping to get more feedback from other contributors first, but summer is a busy time for many.

[yioannides]

@cameronwhite Sorry for not responding sooner! I am okay with an "human supervision over LLM above all" approach prior to a PR, as long as people who ignore the AI policy and post garbage regardless are held accountable.

Would love to hear from @pedropaulosuzuki as well.

[pedropaulosuzuki]

Sorry for the delay, I didn't have a PC for the past few weeks.

I'd say we could probably settle on this. Please tell me what y'all think:

• No LLM usage for interacting with us (aligns with @cameronwhite's "No Agent" section). All text must be written by you*.
• LLM usage for finding bugs or security vulnerabilities is 'fine', in the sense of: we don't care how you found the bug, if it exists, it exists. However, you MUST test it and confirm it's indeed a bug before raising an issue. You must write all the text, tests and reproduction steps yourself, no agents or garbage walls of text, or you will be ignored and possibly banned if you're a repeat offender. Code snippets from an LLM should NOT be included on the issue tracker, as they can possibly violate copyright.
• No code generated with LLMs can be used on Pinta. All code must be handwritten by the submitter, without any code from LLM tools, which generate copyright violated material.

*For translations, I found a suggestion somewhere that seems really interesting: if you don't speak english, write in a language you understand, then readers can choose how to translate it (and sometimes the reader already knows that language and can read it perfectly).

While I'm not opposed to the original proposal of allowing the usage of a translation tool before submitting, I can see the appeal on this other proposal, so I'd like to see what you guys think about that.

[Lehonti]

I would like to warn against a blanket ban on LLM-generated code. I understand copyright concerns, but to add to my previous message, and based on my experience:

• Letting an LLM loose for code generation = generally bad, likeliest to generate technical debt and the kind of code that commonly causes concerns. But I think the kind of code that causes concerns could be detected easily (correct me if you think I am wrong)
• Using an LLM with great/excellent guardrails for code generation = not likely to be a concern. I offer to share the guardrails I use in my personal/work projects

I also understand that the pull requests should be bite-sized. But I guess that's a matter of working with others competently, and part of using LLMs competently instead of blindly. If I had to direct my attention to something, it would be this, the huge pull requests which are rude to the person reviewing them.

[yioannides]

Lately I've found myself learning towards the Linux kernel contribution guidelines regarding AI use, specifically:

• allowing LLM-assisted code under the strict stipulation that it's authored by a human who can read and understand the output of the code, as well as be accountable for it in case of major regression due to negligence in proofreading said code
• no "vibe coding" whatsoever (= no autonomous push of poor quality AI slop code with bogus functions or comments etc)

I'm still morally (and environmentally) opposed to AI/LLMs, but I would be remiss to not acknowledge recent strides in Linux with the help of LLMs, as well as contributors like @Lehonti who clearly know what they're doing and have been part of Pinta's development for a long time already (kind of like Flathub's "laissez-faire" asterisk clause of exempting "large / established" projects and contributors from their recently introduced ban on AI)

I'm also worried about any potential copyright infringement, but one may assume it's already happening as we speak and since there's no way to prove it or have a legal entity to prove / enforce it, I propose we focus on the quality of code / PR submission formatting for the time being.

TL;DR : I'm okay with @cameronwhite 's AI policy!

[cameronwhite]

• LLM usage for finding bugs or security vulnerabilities ...

I agree on this - it's kind of implicit in the No AI-generated text in human-to-human communication section but probably worth adding an additional note for clarity. I'm definitely not a fan of dealing with giant wall of text issue reports :)

• In terms of translations I'm also fine if someone leaves text in their native language, but generally in the past I've seen people submitting issues with an English translation so I think that's fine to let people continue doing and not have any specific policy on

• On the LLM usage for code, we clearly don't have an obvious consensus :) I'm inclined to keep the current proposal of no usage for non-trivial changes, which is the main area for issues with copyright, code quality, and burden on reviewers

[toepel]

@cameronwhite Sorry for not responding sooner! I am okay with an "human supervision over LLM above all" approach prior to a PR, as long as people who ignore the AI policy and post garbage regardless are held accountable.

Would love to hear from @pedropaulosuzuki as well.

One Question here, is that just for the Pinta code itself or for Pinta Add-ons as well?
I'm asking, because I want to create an AI-Addon for Pinta at the moment.
To have some "Firefly like" functions, but with open source and bring your own-model capabilities.
And of course I'm not the expert for all of these principals in behind, so I co-create it with Claude Code, some Guardrails and Agents.

At the moment I'm heavily in creating the concepts for all the different functions but have some rudimentary function in the Add-on already running.

I want to give it to the community afterwards, but just when you as the main contributors give green light on that.

[cameronwhite]

This is just for Pinta code itself - Pinta add-ins can have their own separate licenses already (https://github.com/PintaProject/Pinta-Community-Addins#licensing) so I don't think there should be any specific policy for add-in projects