sudara

Joined 18 years ago

Karma
216
Submissions
69
Member since
Mar 11
Building an additive synth with 10k time domain oscillators (and blogging) over at https://melatonin.dev
View on Hacker News

Recent submissions

Comment · 11 months ago
Love the chorales, thanks for sharing that one.
Comment · 2 years ago
This is amazing, I will def be playing with it (lossy is also my jam) and hi! I made pamplejuce, hope it worked ok for you, lemme know if anything was rough (its been growing up a bit lately)
Comment · 3 years ago
Comment · 3 years ago
Thanks for this!
Comment · 3 years ago
OMG would have loved to do that instead.
Comment · 3 years ago
Cache locality and specifically the vertical pass was top of my mind when trying to come up with good ways to vectorize. In the end (at least in my vector implementations) the difference between the passes weren't too large. But most of the them ended up having to do things like first convert the incoming row/col to its own float vector.

One main issue I never resolved is in the middle of the main loop, data has to be converted and written back to the source image and the incoming pixels have to be converted and loaded in. Even when doing all rows or cols in bulk (which was always faster somehow than doing batches of 32/64), that seemed pretty brutal.

I also wondered whether it might be more efficient to rotate the entire image before and after the vertical pass, but in my implementations at least, there wasn't a huge difference in the pass timings.

Comment · 3 years ago
> If you take a look at the video in my README, you'll see how bad it is.

Ahh, the video threw me off originally, I think because of the FPS glitches on the full width — but I see it now! Big bands of blue on the left and right edges. I'll have to cook up some examples to reproduce. Also curious what it means (if anything) in the drop shadow context.

> I can say there is a huge performance tradeoff in using real division

Makes sense. It would also throw a wrench in my vector implementations, where the expectation is to perform the same operation efficiently across groups of pixels.

> and that my library was therefore the best :)

Haha, well it was for me! I don't know Rust, but it helped me figure out my first C++ implementations!

Comment · 3 years ago
Fixed! Sorry about that. The rustrepo stuff confused me!

My question is — was solving the edge bleed worth the (assumed) performance tradeoff? There were a couple vendor APIs that seemed to have smarter edge bleed options, but they performed worse. I never got around to actually visually comparing the images, though...

Thanks for all the great comments in your repo, they were quite helpful when trying to figure out how Stack Blur worked!

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton