How much your computer can do in a second

Anyone care to rewrite these into c#? I am really surprised how fast these python scripts are and I would like to see comparison with equivalent tasks in c# where it stands..

True, at least without using any vendor-specific extensions (that may or may not help here; I haven't investigated). My point was that in CL, you get close-to-C++ performance levels by default, you can get even closer by optimizing specific areas in your code, and all of that while still writing in a very high-level language. Of course you won't beat memory-optimized C++ code in performance, but you're already close enough that you rarely need to.

That was so acid. ;-)

But besides my pun, "fast" code is a moving target relatively to the end result (see how performance considerations about Java running in a VM became moot because of hardware improvements notably on the CPU; see how today multithreading is making a comeback to rescue CPU-bound applications from stale improvements).

Fast is also subjective, it's cultural in that it's a trained perception. I'm annoyed if Excel takes more than a couple seconds to launch, but most people are used to 10s at least, because that's our daily experience. Likewise, I remember a time when having pixelated thumbnails until images loaded completely over dozens of seconds was the best browsing experience; nowadays on fiber/LTE we expect a page to appear rather instantly.

I guess what subconsciously annoys the hell out of "those who like as fast as possible applications" with Electron is that we know it will yet make fast a more distant concern overall, at least until hardware makes the Electron performance penalty moot, like Java VM.

I'm pretty convinced 'fast' is indeed a clear third priority for most consumers though, seeing how it doesn't seem to bother most people in UX research (less so than many other concerns), or how Apple rides ever more financial success while releasing ever slower hardware and software (comparatively to the whole market, and sometimes astonishingly even to their own previous models). Facebook is bloated as hell too these days, but it's as popular as ever. Spotify is sluggish too, even Twitter. People just don't seem to care, the looks and simplicity of use seem more determinant.

>If you're doing image processing in WebGL, then to write many pixels to a framebuffer all at once, you draw a single polygon that covers the entire viewport. Your shader is applied in parallel to all pixels drawn. That is how ShaderToy works, it renders a single quad to the viewport and applies whatever shader you give it, the GPU runs that shader on all pixels rendered.

>Whoa, hang on. Hey I only mean this to be helpful not insulting, but it sounds to me like you may have some misconceptions about the way WebGL works.

You draw a simple quad, which the shader then processes all the pixels in parallel, returning their frag_color as the output color. It can read textures and other source information, but it does not have access to what is being processed currently for other pixels, because its parallel. You have to wait until it has rendered that, and then pass it in again. I am unsure what I am misunderstanding.

>https://webglfundamentals.org/webgl/lessons/webgl-image-proc...

This was a cool insight into using framebuffers for multiple passes, thank you.

>Here is the demo from that article that uses the techniques I've been talking about. All of the filters in this demo are doing neighborhood computations. And note you can apply multiple filters. There is no texture copy here, this tutorial renders directly to a texture in one pass, and then samples that texture in the next pass and so on. The iterations or feedback that you're looking for happen by combining render-to-texture with drawing the viewport polygon multiple times.

From what I'm seeing, this is not just a couple passes, its a pass per-filter. None of the filters singularly rely upon multiple passes, their output is calculated purely on the image that was filtered before it, meaning the filter itself doesn't need to write pixels and then read them again. You can see that in the for loop that calls setFramebuffer() and drawKernel(). I understand that you can apply a shader, and put its output back in, but I still fail to see how you're avoiding doing that at the very least in the hundreds of thousands of times. error diffusion dithering classically is sequential from top to bottom, or bottom to top depending upon serpentine or not, I don't think you can just process a ton of pixels at the same time and still look anything like a sequentially done Floyd-Steinberg.