2012/5/14 Till Oliver Knoll <till.oliver.kn...@gmail.com>:
>>> ...
>> How about using QSharedMemory for the actual JPEG data, and use either
>> the QLocalServer/Socket or a StdIn/StdOut approach for the notifications
>> that there is something to read? Seems more efficient than (de-)
>> serializing images all the time.
>
> I assume you mean the de-/serialisation effort required when trying to
> send binary data over a "text-based connection" such as stdin/stdout:
> I would have to use e.g. Base64 encoding.
Ah I think now I understand what you mean by de-/serialisation effort:
you probably meant that on the sender's side I would store a QImage
into JPEG ("serialisation"), send that JPEG data over to the child
process and there re-assemble ("deserialise") another QImage by
loading the JPEG data from memory?
Indeed, in the parent process I do have a QImage which I then store
into a memory buffer as JPEG. But this is simply because I really need
the "raw" JPEG data in the end, to upload to an AppleTV device via
HTTP (and yes, really the binary raw data stream, not Base64 encoded).
If I can make sure that the file on disk is a) a JPEG file and b)
already of proper size ("720" or "1080" in height, depending on the
device's capabilities) I could even skip the part of loading and
scaling with QImage, and read the QFile data and send it over to the
"networking enabled process" 1:1.
In other words: my JPEG data is not the serialised form of my data, it
/is/ the data ;) And sending that binary data over a local socket
should not have any noticeable serialisation effort at all.
Cheers, Oliver
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
