SharedBuffer currently offers a mixed bag of semantics:
* efficient/segmented append
* efficient sequential access
* consolidated-data and random access
* no thread safety
Due to the lack of thread safety, we are forced to make a copy before passing the data to rasterizer/image decoding threads. In order to avoid duplication, the original data is discarded - and (if later needed on the main thread) recreated on-demand, via another copy.
The supporting code is quite complex; this is a tracking bug for related work, as an effort to simplify/improve SharedBuffer.
Some ideas:
1) remove the random-access methods - no clients seem to actually need them
2) remove the data-flattening methods - most clients seem like could be trivially refactored for segmented access
3) make SharedBuffer thread-safe to avoid copying data - SkRWBuffer and its read-only/thread-safe snapshot mechanism seem like a good semantic match
Comment 1 by fmalita@chromium.org
, Jun 1 2017