> > 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. >
yes, this is how MR does it as well. in my experience, there are a few issues with this design: - after detecting a change to the file, iv first needs to contact the driver and tell it that it is ready to receive data. if it is a quick render with small buckets and there is a long enough delay after detecting a change to the file, by the time that the connection is first established several tiles may have already finished. that means that the render driver needs access to previously rendered tiles, either through its own internal buffering or through the renderer's API. i don't like the added complexity or memory overhead. - if the driver is now acting as the server listening for an incoming connection, and the stub file tells IV which port to use to connect to it, how do we ensure that the provided port is unique amongst all running instances of the driver? - apps like maya base the name of the file they are rendering on the scene name. if we take the approach of MRay and name this special file the same name as the image it is about to render, then every time the maya scene name changes we have to repoint IV to the new file (which may not even exist yet). this problem could be mitigated easily enough by choosing a fixed name for the socket info file. as far as i can tell, the primary advantage of such a scheme is that you can connect to any render in progress, and stream out all the previously rendered tiles as well as receive new tiles as they complete. hmm... that could certainly be handy. i'll have to see if arnold allows access to previously rendered pixel data from inside the driver. i'll certainly consider this approach in the future. my current method of starting a server on IV to listen for incoming connections is simple and effective and will suffice for now while I work out the much more difficult issue of triggering the ImageBuf class to reload a specific tile. if anyone has any suggestions on how to tackle that beast, I am all ears. -chad 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 > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
