Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some improvements to the SharedAsset system #971

Merged
merged 20 commits into from
Oct 29, 2024
Merged

Conversation

kring
Copy link
Member

@kring kring commented Oct 29, 2024

This is a PR into #926.

  • SharedAssetDepot is now templatized on both the asset type (such as ImageAsset) and on the type of the unique key used to identify specific assets. Previously the unique key was always a string (the URI).
  • Added IDepotOwningAsset, which is the interface by which SharedAsset references the SharedAssetDepot that owns it. And moved most of the depot-specific fields out of SharedAsset and into private AssetEntry class in the SharedAssetDepot. This approach allows us to avoid templatizing SharedAsset on the asset key type.
  • Added NetworkAssetDescriptor and NetworkImageAssetDescriptor, which are classes intended to be unique keys for identifying assets.
  • Added TilesetSharedAssetSystem. This is just a bit of future-proofing to allow us to have tileset-specific shared assets in the future.
  • Renamed pAssetDepot in TileContentLoadInfo to pSharedAssetSystem, because it's not an asset depot.
  • Removed unnecessary #include of AsyncSystem.h from IAssetAccessor.h. Only Future is needed, not AsyncSystem.
  • Made SharedAsset copy constructor and assignment operators protected. It's ok to copy an ImageAsset, but copying a SharedAsset<ImageAsset> would result in slicing.
  • Removed the store method from SharedAssetDepot, because dealing with the edge cases of this (such as calling it after a request to get the asset is already in flight) was tricky, and it's probably not very useful anyway. This means that only assets created by the depot can be associated with it, which is probably fine.
  • Made the asset factory a std::function rather than an interface, since it's just one function.
  • Some renames in SharedAssetDepot:
    • staleAssetSizeLimit -> inactiveAssetSizeLimitBytes for consistency with terminology used elsewhere.
    • getDistinctCount -> getAssetCount
    • getDeletionCandidateCount -> getInactiveAssetCount
    • getDeletionCandidateTotalSizeBytes -> getInactiveAssetTotalSizeBytes
  • Added SharedAssetDepot::getActiveCount.
  • Removed SharedAssetDepot::getUsageCount, because it's peering into implementation details, and I don't think it's needed.
  • Made markDeletionCandidate / unmarkDeletionCandidate take a const asset, since conceptually they modify the depot not the asset.
  • Added CesiumUtility::Hash::combine function, ported from Boost. Updated a couple of places we were combining hashes to use it.
  • GltfSharedAssetSystem::getDefault no longer takes an "options" object. Which is good because it was always ignored after the first time the method was called.
  • Made sure asset load errors flow through correctly so that they can be reported to users.
  • Removed isOrphan from DoublyLinkedListPointers, because it seems weird to call a node an orphan when its the only item in a list, and we can't distinguish that case from an actual orphaned node. Added a contains method to DoublyLinkedList instead. It works in constant time with the caveat that it can'd distinguish "in this list" from "in some other list". The caveat is documented.
  • Added helper static functions to ErrorList to create an instance with one error (error) or one warning (warning).
  • Added CesiumUtility::Result<T>, which is is a handy container for some result instance plus an ErrorList to capture any warnings and errors that occurred while producing it (or failing to produce it). Also added CesiumUtility::ResultPointer<T> for convenience when the value happens to be an IntrusivePointer. There are a few places in the code that have custom containers for the same purpose, such as GltfReaderResult. We should switch them to use this type instead, but it need not be part of this effort.

/**
* @brief Determines if this list contains a given node in constant time. In
* order to avoid a full list scan, this method assumes that if the node has
* any next or previous node, then it is contained, then it is contained in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small typo here. "then it is contained, then it is contained"

* be at least one error in this list.
*/
ErrorList errors;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we indeed end up using this type for more than just this feature, it would be lovely to add a lot of the convenience features you find with Rust's Result type. For example, a match method that runs one lambda if Ok, or another lambda if Error. Or a map_value method than can turn a Result<T, E> into a Result<T2, E> using a provided lambda. We don't need to add these now, just thinking out loud.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to build on std::expected? I think we're already using expected-lite here in native.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually used nonstd::expected in an early iteration of this, but the problem is it doesn't offer a good way to represent "success, with non-fatal warnings." Which is a fairly common phenomenon in cesium-native.

I definitely agree that we would benefit from a little work on ErrorList to improve its ergonomics, though. Starting with a rename, because it's weird to call it ErrorList when it also holds warnings.

@azrogers azrogers merged commit f9459d1 into shared-assets Oct 29, 2024
36 checks passed
@kring kring deleted the shared-assets-wip branch October 29, 2024 20:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants