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.
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.
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.