3 ms·

>if software running slowly on your own computer automatically made you optimize it I recently changed 1 byte in Chrome.dll and decreased the lag for copying l

by andai 4y ago

>if software running slowly on your own computer automatically made you optimize it I recently changed 1 byte in Chrome.dll and decreased the lag for copying large images by a factor of 2-3. (The UI freezes for 5-10 seconds. Turns out it's re-encoding a 2MB JPG into a 20MB PNG for the clipboard, at compression level 6 no less!) I put up with it for years thinking there was nothing I could do, but one day I decided to ask some people smarter than me, and they gave me enough info to track down the code in IDA (I had never used it before). My point is, motivation is a powerful thing! (Offtopic but turns out Firefox copies the original file, so you can paste it right into Windows explorer—blew my mind!)

alexchantavy 4y ago
This sounds cool, you should write a blog on it
charcircuit 4y ago
For those curious. https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=736;drc=0c4306fc554c80506eb0f9b833a5d2a5fdd452d5 https://source.chromium.org/chromium/chromium/src/+/main:ui/... An improvement would be to replace EncodeBGRASkBitmap with FastEncodeBGRASkBitmap so that it uses the fastest zlib level instead of the default (6). This is what the Linux X11 (ozone) implementation uses. This would be an easy fix to upstream if someone wants to do it.
- andai 4y ago
  Yeah, like you said they literally already wrote the code that does that, not sure why they didn't use it. Setting compression to 0 is still 2 full seconds of lag for me (down from 8s), so there's still a lot of overhead. There are faster png implementations but I think re-encoding a 2MB JPEG into a 20MB PNG (to be re-encoded back to JPG by whatever program you paste it into) is kind of missing the mark.
  - charcircuit 4y ago
    Funnily enough a CL moving the computation to a background thread was submitted a week ago. This would prevent the UI freeze. https://chromium-review.googlesource.com/c/chromium/src/+/4216473/2#message-d71ab0b025a75a11023f8bd324d041d91bc9c99f https://chromium-review.googlesource.com/c/chromium/src/+/42...

by andai 4y ago

alexchantavy 4y ago

This sounds cool, you should write a blog on it

charcircuit 4y ago

For those curious. https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=736;drc=0c4306fc554c80506eb0f9b833a5d2a5fdd452d5 https://source.chromium.org/chromium/chromium/src/+/main:ui/... An improvement would be to replace EncodeBGRASkBitmap with FastEncodeBGRASkBitmap so that it uses the fastest zlib level instead of the default (6). This is what the Linux X11 (ozone) implementation uses. This would be an easy fix to upstream if someone wants to do it.

andai 4y ago
Yeah, like you said they literally already wrote the code that does that, not sure why they didn't use it. Setting compression to 0 is still 2 full seconds of lag for me (down from 8s), so there's still a lot of overhead. There are faster png implementations but I think re-encoding a 2MB JPEG into a 20MB PNG (to be re-encoded back to JPG by whatever program you paste it into) is kind of missing the mark.
- charcircuit 4y ago
  Funnily enough a CL moving the computation to a background thread was submitted a week ago. This would prevent the UI freeze. https://chromium-review.googlesource.com/c/chromium/src/+/4216473/2#message-d71ab0b025a75a11023f8bd324d041d91bc9c99f https://chromium-review.googlesource.com/c/chromium/src/+/42...