New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 742506 link

Starred by 3 users
Status: Available
Owner: ----
Cc:
xiy...@chromium.org
█ fsam...@chromium.org
m...@chromium.org
dsinclair@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

cc.mojom.CopyOutputResult could cause huge data volume over message pipe

Project Member Reported by m...@chromium.org, Jul 13 2017 
cc/ipc/copy_output_result.mojom defines a CopyOutputResult struct (and struct traits) to adapt cc::CopyOutputResult for use with mojo APIs. Unfortunately, there are many common cases where the size of the bitmap carried in this struct can be huge (i.e., several megabytes), which means the struct could easily overwhelm and stall the IPC channel between VIZ and browser process.

Therefore, the struct should instead provide a handle whereby the consumer would access the bitmap data on a side channel (e.g., a mojo data pipe or shmem buffer).

The details of this process could be seamlessly hidden from client code via the struct traits implementation. It could manage the transfer of the bitmap by transferring the bitmaps of cc::CopyOutputResult via some mechanism outside the mojom struct; and then later on the client-side, re-build a cc::CopyOutputResult, automatically populating the bitmap data from the outside mechanism.

Comment 1 by thestig@chromium.org, Mar 22 2018 

Did this go anywhere? Right now for printing, we write temp files to disk with [PDF, EMF, PostScript, PWG] data, and then pass the file handles to Mojo for transport. The data is oftentimes small, but can be large. To do this, we have to manually bounce between the UI thread and a blocking task runner. It would be nice if we didn't have to do that and just use Mojo DataPipes. But then we run into this issue.

Comment 2 by m...@chromium.org, Mar 22 2018

Cc: xiy...@chromium.org
No, but it still needs attention! I think the issue is that there isn't anyone available to work on it.

FWIW, I did a scan using the following:

  find chromium/src/ -name '*.mojom' | xargs grep -i bitmap

...and it seems that almost all mojo SkBitmap APIs use the skia/public/interfaces/bitmap.mojom; which never uses shmem, unfortunately.

Then, there is a TODO comment in ui/gfx/image/mojo/image.mojom that suggests their SkBitmap struct traits (that ONLY use shmem, never the message pipe) could be merged into bitmap.mojom.

What would be ideal is a single struct traits solution that sends "small" SkBitmaps over the message pipe, and larger ones using shmem. I'm not sure what the threshold for "small" should be...maybe 4 KB or 8 KB?

Comment 3 by xiy...@chromium.org, Mar 22 2018 

gfx.mojom.ImageSkia uses shared buffer for transport. Can we use that instead of skia.mojom.Bitmap ? 

Last time I tried to change skia.mojom.Bitmap to use shared buffer, I hit a bump that it is used inside sandboxed renderer and could not create shared buffer.

Comment 4 by m...@chromium.org, Mar 22 2018 

Regarding the sandboxed renderer issue: I wonder if the struct traits could detect this case, and just fall-back to using the message pipe (AND also follow-up with feature owners to fix their SkBitmap transport mechanism to avoid clogging-up the mojo IPC transport).
►

Sign in to add a comment