I promise I will comment on this tonight!!
On Jun 20, 2012, at 1:24 AM, Chad Dombrova wrote: > does anyone have ANY thoughts on this? i'm not really sure how best to > proceed at this point. i've made a lot of progress on this and it'd be a > shame for it to go to waste. > > -chad > > > > 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
