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] > <mailto:[email protected]>> wrote: > How does this look, Soren? https://github.com/OpenImageIO/oiio/pull/1438 > <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] >> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> > <mailto:[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] <mailto:[email protected]> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <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
