Hey Larry, Soren's gone home so I'll answer for him. Our production OIIO is at 1.6.10 at the moment. We're playing with 1.6.14.
Would your diffs apply or would we need a backport? Cheers Dan On 27 June 2016 at 18:50, Larry Gritz <[email protected]> wrote: > Søren, do you guys work from master, or do you need a backport? > > > On Jun 27, 2016, at 10:43 AM, Søren Ragsdale <[email protected]> wrote: > > Sorry for the delay in responding. > > > I've read through the diffs. If I understand correctly, I should be able > to: > > - ask for "total_files" and get the total number of textures that OIIO > knows about > > - ask for "all_filenames" and get back a list of all the textures that > OIIO knows about > > - run a query on each of those files and get back > bytesread, redundant_tiles, and other things that OIIO knows about each > texture. > > > That seems pretty useful, and seems sufficient for my purposes. Thanks! > > > On 18 Jun 2016 8:39 p.m., "Larry Gritz" <[email protected]> wrote: > >> How does this look, Soren? https://github.com/OpenImageIO/oiio/pull/1438 >> >> Look at the last part of the diff, the part of testtex that exercises it. >> Look reasonable? I think this will let you extract the information you need >> and pack it into whatever statistics format you prefer. >> >> >> On Jun 16, 2016, at 11:54 AM, Larry Gritz <[email protected]> wrote: >> >> Yes, it would also require a global TextureSystem::getattribute query >> that returns the list of all files accessed. That would be true regardless >> of whether the per-file stats are accessed via get_texture_info, or if you >> had direct access to the internals of the ImageCacheFile struct -- either >> way, you sill need the list of files. Giving access to the deep internals >> of the data structure necessary to construct that list yourself seems well >> into "TMI" territory. No good can come from making those internals part of >> the public API and losing the freedom to change them at will. >> >> Let me mock something up and make a preliminary PR, and see if it looks >> like the right direction, and then if so, I can make it more complete. >> >> -- lg >> >> >> On Jun 16, 2016, at 2:04 AM, Søren Ragsdale <[email protected]> wrote: >> >> I'm not sure that's a good solution in this case. I don't want to ask >> about any particular texture - I'd like to get a list of all the textures >> that OIIO knows about, at which point I guess I could query the statistics >> for each one of them. >> >> On Thu, Jun 16, 2016 at 12:59 AM, Larry Gritz <[email protected]> wrote: >> >>> I'm uncomfortable exposing the internals of the file record struct from >>> the ImageCache. >>> >>> But I can offer a cleaner solution: >>> >>> Just like you can retrieve various TextureSystem-wide statistics via >>> TS::getattribute("stats:foo", ...), perhaps I can add an API function that >>> lets you ask for statistics associated with a particular file. In fact, we >>> should probably simply use the existing get_texture_info(), and I can make >>> it aware of tags that retrieve the statistics. Then you can retrieve those >>> in a way that's not dependent on the internals which may change, and >>> assemble them into the XML or any other format you want. >>> >>> Does that sound reasonable? >>> >>> >>> > On Jun 15, 2016, at 3:05 AM, Søren Ragsdale <[email protected]> wrote: >>> > >>> > OIIO provides a OSL::TextureSystem.getstats() call, which is useful if >>> you'd like to see OIIO stats represented as one large string. >>> > >>> > We're using OIIO inside OSL inside Prman-20. I'd like to stuff OIIO's >>> texture access stats into Prman's XML-formatted logfile. But in order to do >>> this, we need to have access to m_files which is a private member. >>> > >>> > Could we get some kind of const access function for m_files? >>> > >>> >>> -- >>> 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 >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> _______________________________________________ >> 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 > > > -- > 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
