Last time I implemented this code for Gelato's iv, we used a file-based mechanism to handle the steps in the list below so that you just kicked off a render and automagically a new image is created and the data started to stream from the renderer to iv. Most of our time was spent revising the protocol used to send tiles, since we wanted to be able to handle tiles out of order and other tricky bits that we messed up in the initial implementation. The unimplemented code in SockingInput likely originated from our memory of how it worked in Gelato.
As I recall, we had a watch on a particular file (this worked under both Linux and Windows) which notified iv when the renderer had written some data. Then iv read the data, created a new image, opened up the port for listening, and then waited to receive tiles from the renderer. We had to be careful to properly handle multiple simultaneous streaming renders on different ports, with tiles arriving in arbitrary order (which implies updating texture and redrawing appropriately). On Mon, Mar 26, 2012 at 3:57 PM, Chad Dombrova <[email protected]> wrote: > 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 > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
