Conversation
This makes clip image data around twice as fast, it's a little tricky to measure it though. Changes: - Work on Uint32Array instead of Uint8 so it's 1 assignment per pixel instead of 1 per channel. - Perform the clipping in-place using the original image data to avoid allocation a new buffer. Fixes xtermjs#4197
|
👍 Nice. The GC pressure should also be much lower, but note that most of the runtime in your original post came from GC itself, prolly meaning that the GC books already were pretty full. Thus there is a high chance, that the additional objs from that method only "brought the barrel to overflow" (german saying) forcing the GC into serious cleanup. |
| clippedData[newOffset + 1] = imageData.data[oldOffset + 1]; | ||
| clippedData[newOffset + 2] = imageData.data[oldOffset + 2]; | ||
| clippedData[newOffset + 3] = imageData.data[oldOffset + 3]; | ||
| const clippedData = new Uint32Array(imageData.data.buffer, 0, width * height); |
There was a problem hiding this comment.
Oh well - inplace overwriting is abit dangerous, if the overlapping from rewrites is not safe (guess its ok here?)
There was a problem hiding this comment.
It's safe as the data is read from low to high and the writing is always the same as writing (rare) or lower
| } | ||
| } | ||
| return new ImageData(clippedData, width, height); | ||
| return new ImageData(new Uint8ClampedArray(clippedData.buffer, clippedData.byteOffset, clippedData.byteLength), width, height); |
There was a problem hiding this comment.
Not sure if it is worth the trouble - since you already do inplace overwriting above, the new ImageData maybe can also be avoided?
Which raises the question - is the _clipImageData method needed at all? As far as I can see it just transfers a rectangular subarea over. Isnt it faster to simply take the orginal ImageData and apply the box offsets during drawImage? But maybe I am overlooking something...
There was a problem hiding this comment.
You're right! We can remove this outright and just use boundingBox in drawImage. I'm guessing the reason it's as it is currently is because I just overlooked that or wasn't thinking drawImage had a this signature source+dest signature.
There was a problem hiding this comment.
Was just doing this, we can't actually use drawImage as it doesn't accept ImageData, looks like we can still use putImageData though.
There was a problem hiding this comment.
Oh right, was mixing the methods up (I use putImageData myself, lol) 😊
Though the question remains, if thats actually faster, or just creates runtime noise at different ends...
There was a problem hiding this comment.
Surely it's faster, it's essentially doing what was being done manually before natively
2 participants
This makes clip image data around twice as fast, it's a little tricky to measure it though. Changes:
Fixes #4197