Hi, We may need some kind of helper function that implements the "listen for a > connection" part, and when that says that a connection is ready, then we > can open the socket ImageInput and pass it a hint that gives the specific > name or port number or whatever to read from. We need not strictly > restrict ourselves to the existing ImageInput interface; it's ok to add > something socket-specific to get things started. It need not be generic; > any app listening to sockets is going to damn well know that's what it's > doing. But once the socket is established, it would be nice if the rest of > the interface for actually reading the pixels from the socket was through > the II. >
cool. then all this is done. I've written a SocketServer class that listens for incoming connections and calls a callback with the incoming file name. I currently have it as part of openImageIO library. Does that work for you? Another thing that needs to be shoehorned in is that the socket may not > communicate pixels in scanline or tile order, and aren't necessarily ready > at any given time. We'll need a way to ask the socket connection if another > scanline or tile is ready, and which one it is. We may be able to use the > existing send_to_input()/send_to_client() mechanism for this; it's in place > for this kind of thing but so far has not been used. > I've handled this with a tile_changed_callback. Colin pointed out that it could be useful for other types as well: ImageInputs for formats like exr and tiff that support writing tiles to open files may want to spawn a new thread to watch for file changes and then call the tile_changed_callback. the next thing i need to do is figure out edge tiles, as we discussed a bit earlier. the SocketInput receives "cropped" tiles over the socket, but the pointer passed in from the ImageCache is handing it "full" tiles. I saw some recent commits related to this discussion: is it still the case that the ImageCache allocates "full" memory for "cropped" tiles? -chad > > -- lg > > > On Jun 9, 2012, at 12:50 AM, Chad Dombrova wrote: > > > Hi all, > > I mentioned in an email earlier that I have a rough prototype of socket > rendering working via oiio into iv. The purpose of this email is that I am > having trouble making the socket rendering model fit within the oiio > "open/read/close" ImageInput model. At first glance they may seem > compatible -- open a socket connection, read the tile data, close the > connection -- but there are serious problems lurking once you dig deeper. > > > > Consider the typical socket rendering scenario: > > > > 1. start a listening server > > 2. on connect from client, create a new image buffer > > 3. read tiles from client into buffer > > 4. close connection > > 5. repeat steps 3-4 (possibly at the same time) > > > > In this scenario, there is a single server listening on another thread > all of the time: before, after, and during a socket render. The server > handles all incoming connections and creates the SocketInput instances, > which handle the remainder of the data streaming for that connection. In > the "open/read/close" model, on the other hand, each SocketInput acts as > its own server, valid for a single connection only. What this means is > that a new SocketInput must be created *prior* to each new render > performed. I'm very opposed to placing this burden on the user, but > performing the convoluted code trickery in IV required to lift that burden > is not attractive either. > > > > There is other fallout as well. For example, in the ideal/typical > scenario, when the server accepts a connection from a renderer, the first > thing it does is get the filename of the image about to be sent. though > the image does not exist on disk, the file name serves both as a unique > handle in the case of multiple simultaneous renders, and as something > useful to display in IV to identify the image. Since the name can't be > changed once the ImageInput is created, we would either force the user to > enter in a new name prior to each render or use the same name for all > socket images. > > > > So, what is the best solution? Perhaps we could abstract the server > model down to an "image generator": a function that runs on a separate > thread and generates new ImageInput instances. plugins could register > these generator functions, if they apply. Are there any other file formats > that would benefit from some kind of abstracted server model? I'm really > not sure what else could benefit from such a thing, but I'm trying to work > within the plugin framework to avoid treating sockets as a special case. > > > > Any guidance on this would be greatly appreciated. > > > > -chad > > > > > > _______________________________________________ > > Oiio-dev mailing list > > [email protected] > > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] > > > _______________________________________________ > 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
