Hi all,
I’ve finished a fairly thorough investigation into the socket classes and made
some headway toward a working solution. the current implementation in oiio
master is far, far from complete (i would call it more the beginning of a
sketch). Before I delve into the details of what's missing, first let’s
outline how we would like IV to behave when performing socket renders. From a
user’s perspective, here's what I'd expect:
- in IV: choose port, start server listening
- in Renderer: choose matching port, start render
- in IV: new image is created and each new tile is displayed as it arrives
until render completes or aborts
- in Renderer: start new render
- in IV: a new image is created …
what I’d like for us to agree on is that the user should not need to create a
new image in IV prior to each render he wishes to perform, but rather that each
new render should automatically produce a new image (so that previous renders
can be compared to each other, etc).
Ok, if we can agree on that, then let’s move on to what needs to be done.
As it currently stands, SocketInput requires an instance to be created prior to
each render, which is not what we want. In order to get the desired behavior,
I’ve written a small server that runs on a separate thread within IV. When it
receives an incoming connection, it executes a custom callback and passes it a
“filename”, such as "foo?port=10110.socket" (this was a naming convention
established in the current implementation). In the case of IV, the callback
adds a new “socket” image to the viewer and makes it the current image, by way
of ImageViewer.add_image().
With my modifications, once the SocketInput class has been created, it
asynchronously processes incoming tiles, by first reading a restful header that
specifies the tile data that is about to be read (ex. "tile?x=576&y=448&z=0"),
and then, in theory, by reading the tile data. The reading occurs on a
separate thread so the UI remains responsive.
Now I need some guidance. When a SocketInput instance gets a callback
indicating that a fresh tile has arrived, what should happen next? In the
normal scenario, read_native_tile() would be called with some pre-allocated
space to put the tile data, but this is called by way of ImageBuf or ImageCache
based on a fixed tile iteration scheme. How can a SocketInput instance notify
the ImageBuf or ImageCache above it to reload a particular tile and pass in
some memory to store it? I was thinking one approach might be to allow an
image format to supply its own tile iterator, which in this case would be
controlled/guided by the incoming tile callbacks.
also, I noticed these as yet unimplemented methods of SocketInput:
/// General message passing between client and image input server
///
virtual int send_to_input (const char *format, ...);
int send_to_client (const char *format, ...);
perhaps if these were finished they could be of some use in notifying IV of a
change.
Any advice on this topic would be greatly appreciated.
thanks,
-chad
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
