Ike. That's horrible.

Taking a few brief moments to try and unwind what sv_utf8_downgrade() does, it appears to involve multiple passes (2 or 3) of the data, potentially with one of those passes calling a function on every 'char' in the data! I'll admit, my attempt to unwind the layers was cursory and I may have missed some subtlety in the macros/nested function call definitions.

You'd have to benchmark to be sure, but given that base64 encoding and decoding is a single pass process either way, it's possible that incurring a bytes->utf & utf->bytes cycle in order to avoid the binary->base64 & base64->binary could well be a deoptimisation? Of course, I'm assuming that Perl/Tk doesn't also convert the base64 to utf?

Without even having begun to have considered any other implications, it seems to me that the idea of passing a pointer to the binary image data, directly into the image handling code makes even more sense?

There's also that passing (say) a 1024x768x24 image as binary data in GD's gd(1) format involves 3 MB of uncompressed data that these conversions would need to process (along with all the memory alloc/deallocing that would involve), whereas passing (say) png, that same data could be only a few Kb in it's compressed form. It's possible that the extra processing required to do/undo the utf conversions on the uncompressed data would counterbalance the savings in not compressing/decompressing through an intermediat format?

Geez. Unicode certainly has a lot to answer for. Perl (and everything else) really needs a new variant of the SvPV that has a flag (or combination of existing flags) that says 'This is binary data of CUR bytes. It should *never* be implicitely converted, inspected for conversion, nor up or downgraded in any way'. And all the macros/functions that do any of those things just see that flag and do nothing.