Description
It performs 500K OPS / SEC, one operation is matching or not two colors from their distance and then blend them according to some weight we process from the number of their clones in the image, if a color doesn't match their is no change and it is not counted as one operation here above.
Between attempts to blend colors if they match a certain distance that change what does the attempts differ from others one so we can use small or bigger step to reduce the color gravy! Each attempts or steps colors are putted in a cluster and reduced down to a palette and indexes to constitute the image data that change...
[EDIT Updated link] The code is here :https://github.com/pixa-pics/pixa-pics.github.io/blob/main/src/js/utils/quantimat/QuantiMat.js
We used tactics that really kill the king WebAssembly, look, for color's operation we use a class and operative architecture close to "Single Instruction Multiple Data" SIMD tactic which enables to use lanes of same instruction that gets cached in the micro-cpu-cache to operate better than scalar operations...
And well, for color quantization except that everything that stays an Integer in code is coerced with "| 0" to tells the compiler here will always be a Integer.. just as ASM.JS does and that we reuse the Typed Arrays (within JS) we allocate at first initialization to avoid getting the garbage collector working in-between our operations, yeah it uses some kind of a HEAP and that's it, a few garbage collecting tasks, all Integer explicitly coerced into Integer that are so (We know JS behavior..." and using slices to operate in near-parallel. A very well implemented SIMD functioning is already 3.5x faster, my source are https://github.com/tc39/ecmascript_simd
Top comments (0)