OK, understood… thanks!
Regards, Bernhard > On 18 Jan 2016, at 21:35, Cirilo Bernardo <cirilo.berna...@gmail.com> wrote: > > On Tue, Jan 19, 2016 at 5:14 AM, Bernhard Stegmaier <stegma...@sw-systems.de > <mailto:stegma...@sw-systems.de>> wrote: > Hi, > > I didn’t try(check it, so maybe just dumb questions: > What is the difference between the cached and original files? > I guess most of the time the config folder will be on the same storage as the > original files (== home folder), so what’s the point of copying them to a > cache folder? > It would probably make sense to be able to configure the cache folder (or use > sth like $XDG_CACHE_HOME), so it could be directed to e.g. a tmpfs in RAM. > > > The cache files are a binary format and are an intermediate data > representation. > The existing scheme for 3D models is to parse them and put data into an > S3D_MASTER object. The translated data is not suitable for caching and > each instance of the same model file takes up more and more memory. > With the intermediate format each model is loaded only once so less memory > is used. In foreseeable future cases the intermediate format will also make > the subsequent model load times much faster in cases where creating the > display data is a compute-intensive operation, for example with rendering > MCAD data. The intermediate representation also means that each 3D > model plugin must translate to this one common data format which is > understood by the cache system; this also makes it possible to implement > a VRML output without much additional code since there is now a single > point of translation from intermediate format to VRML. In the legacy scheme > this would have been very messy to implement with each parser > implementing its own translator and VRML export routines - the parsers would > essentially be translating the model twice (once to S3D_MASTER then again > to VRML). > > The cache file also speeds up model loading because it stores its own > computed normals. In our collection of VRML models I have noticed that > in the majority of cases there is either no normals data or the normals > data is bad. In the 3D plugin implementation all normals are calculated; > at this point I can't think of a scheme to select between calculated and > in-model normals on a per-model basis. Perhaps we can make such a > refinement in the future. > > You can always link your cache directory to a RAMFS if you wish. > > - Cirilo > > > Regards, > Bernhard > > > On 18 Jan 2016, at 19:02, Mário Luzeiro <mrluze...@ua.pt > > <mailto:mrluze...@ua.pt>> wrote: > > > > Hi, > > > > For a) I think for this cache mechanisms there should be some way to > > versioning the files or folders or what.. so it will be automatically > > possible to the application to delete that files. > > A possibility would be to hash the file with his own version, so a future > > version will create a different hash.. and maybe there is need for a size > > limit of the folder.. > > > > Just some ideas.. > > > > Mario > > > > ________________________________________ > > From: Kicad-developers > > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net > > <mailto:ua...@lists.launchpad.net>] on behalf of Clemens Koller > > [c...@embeon.de <mailto:c...@embeon.de>] > > Sent: 18 January 2016 11:06 > > To: kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > Subject: Re: [Kicad-developers] 3D refactor update > > > > Hello, Cirilo! > > > > On 2016-01-18 09:59, Cirilo Bernardo wrote: > >> I have reworked the new 3D code and would appreciate some testing/feedback > >> Those who have tried previous versions will need to: > >> a. delete all cache files (in the kicad config. directory under 3d/cache) > >> and > >> b. delete the older 3D search path list (in the kicad config. dir > >> 3d/3Dresolver.cfg) > > > > What happens if somebody forgets to delete these files upfront? > > Are these two steps also necessary in the production version later on? > > > > Regards, > > > > Clemens > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > More help : https://help.launchpad.net/ListHelp > > <https://help.launchpad.net/ListHelp> > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > More help : https://help.launchpad.net/ListHelp > > <https://help.launchpad.net/ListHelp> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp>
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
