If you need UTF-8 inputs from WebIDL (for example if you are passing the
input to Rust), chances are you're doing an extra copy from JS.
In bug 1449861 I've added an UTF8String so that you can convert a
JSString to UTF-8 in a single operation, instead of going through UTF-16.
I can't think if any reason not to use it in places where you take a
USVString / DOMString argument and you turn it internally to utf-8 via
NS_ConvertUTF16toUTF8.
I'd be a bit more wary of stuff that _returns_ UTF-8 output for now, at
least for very-performance-sensitive code. I need to do some profiling
and such to see if it's worth it as-is for CSSOM.
If it's not, it could be optimized teaching JSStrings to store UTF-8
instead of / on top of Latin1 or such, or returning more information
from the callee, but I don't know how easy would be the first (IIRC
we're out of JSString bits), and how worth it would be the second.
Feedback here from JS engine hackers would be much appreciated.
It'd be pretty great to eventually be able to share UTF-8 strings with
JS the same way we can share strings with C++ via nsStringBuffer... But
again that's probably follow-up work.
Anyhow, I hope you find it useful. This is built on top of various great
work by Henri Sivonen, Jeff Walden and others, and the always-helpful
reviews of Boris Zbarsky when dealing with WebIDL. So in the end I
mostly took care of doing the plumbing :-).
Cheers,
-- Emilio
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
