I have a DBus service that creates a Variant type for a Pixbuf file that when saved on either side gives two different files, despite the data being the same. The image saved from the server side is correct, the one on the client side shows the top 1/3 correct, middle 1/3 shifted horizontally by 1/3 of the width and the colors are wonky, and the bottom 1/3 shifted by 2/3 the width and has different wonky colors.
The Variant on the server side is created thusly
var image_var = new Variant ("(iiibi^ay)",
width,
height,
stride,
has_alpha,
bits_per_sample,
data);
and unpacked by the client using
Variant data_var = null;
image.get ("(iiibi@ay)",
&width,
&height,
&stride,
&has_alpha,
&bits_per_sample,
&data_var);
On both sides I print things about the pixbuf, including a checksum. The server side gives
Width: 1024
Height: 768
Stride: 3072
Bits/Sample: 8
Has Alpha: false
Data Length: 786432
Data Checksum: e1facf66095e46d7ca3338b6438c1939
and the client
Width: 1024
Height: 768
Stride: 3072
Bits/Sample: 8
Has Alpha: false
Data Length: 786432
Data Checksum: e1facf66095e46d7ca3338b6438c1939
Everything is definitely the same, the call to save the image for both is
pixbuf.save (filename, "jpeg", "quality", "100", null);
This has been tested and wonkiness has been verified on three different computers. I will provide a complete example, likely tomorrow. I just wanted to put this out there first without it in case someone has come across this before.
Sending large data blobs like images in D-Bus messages is not what D-Bus is designed for — it’s intended for control messages, not large data messages. You’ll get bad performance, and will likely hit the D-Bus message size limits for larger images. See Passing a large data structure over dbus for an example of that.
Instead, you should send a handle to the image data. D-Bus provides functionality for this in the form of the file descriptor type (type string h
), which allows you to pass a file descriptor for the image data from one process to another. The file descriptor could be an unnamed pipe, or could be an open read-only file, for example.