WebAssembly image dithering example

[Allen Garvey]

On Friday, 3 August 2018 at 23:36:18 UTC, kinke wrote:
> And further doubling of that performance [at least for me] with 
> https://github.com/allen-garvey/wasm-dither-example/pull/1. :)

I was reviewing your pull request and it looks very nice, much 
more succinct and roughly 20% faster than my code. It was 
interesting to see what idiomatic D looks like, as I'm sure you 
noticed, my own D style is somewhere between C without the cruft 
and Java compiled to native code :). The only thing is that I've 
noticed a weird visual glitch that I've narrowed down to the use 
of the enum array for some reason, as storing the array on the 
heap is the only thing that seems to make it go away. To see what 
I'm seeing, create a png with width >= 256 pixels and make it 
either completely black or completely white. The glitch only 
shows up once and in the same general place no matter the image 
size, but not at the exact same array index, so I'm baffled as to 
what could be causing it.

> The optimizer apparently figured you were going to dereference 
> a seemingly invalid address (probably `3`, the alpha channel of 
> the 1st pixel, which is read unconditionally in each iteration) 
> and so optimized the whole loop body to a trap (and branched 
> directly to the first unreachable in the 1st iteration).
> These low addresses are perfectly valid and to be expected in 
> wasm though (well, I don't encourage using null though :]). 
> Passing the pointer as argument prevents LLVM from such 
> aggressive optimizations.

I see, that makes sense. The thing that's counter-intuitive to me 
is that if you write the pointer address as 0 right in the code 
it gets interpreted as null, but if you pass in the same value as 
0, everything works as expected. I guess that has to do with the 
legacy of other systems, as only on WebAssembly is 0 a memory 
valid address.

> Ah yeah, that made it into master shortly after beta2. [In 
> beta2, it's `WebAssembly32`.]

That's good to hear.