RenderStateCache: takes pArchiverFactory as input in CreateInfo, let user decide how to get pArchiverFactory

[hzqst]

to mitigate the problem in #701

[TheMostDiligent]

Moving render state cache to archiver is not as easy as that. The cache implementation is still in the GraphicsTools, which means that Archiver needs to use GraphicsTools as dependency. But Archiver is already the dependency of GraphicsTools

[hzqst]

Moving render state cache to archiver is not as easy as that. The cache implementation is still in the GraphicsTools, which means that Archiver needs to use GraphicsTools as dependency. But Archiver is already the dependency of GraphicsTools

Sorry I don't get it, but why GraphicsTools relies on Archiver? or more specifically, which part of GraphicsTools relies on Archiver?

[TheMostDiligent]

Because render state cache is essentially a wrapper on top of archiver.

[hzqst]

Because render state cache is essentially a wrapper on top of archiver.

What about RenderStateCacheImpl takes IArchiverFactory *pArchiverFactory as input through RenderStateCacheCreateInfo and let user decide how to get the factory (either static link or with LoadEngineDll) ? This does minimal impact to current code hierarchy

[TheMostDiligent]

What about RenderStateCacheImpl takes IArchiverFactory *pArchiverFactory as input through RenderStateCacheCreateInfo

This may help, though GraphicsTools will still have dependencies needed for other components in the library.

[hzqst]

I'm good with this except needs for nothing more than xxhash.lib, which is not quite a problem to me.

[TheMostDiligent]

I'm good with this except needs for nothing more than xxhash.lib

I think it will still transitively depend on other libraries (abseil, tint) unless it is taken care of.

[TheMostDiligent]

This is now implemented in f4c2460...a694c58