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

Track image data size independently of the pixelData array size #804

Merged
merged 3 commits into from
Feb 23, 2024

Conversation

kring
Copy link
Member

@kring kring commented Feb 5, 2024

Added a sizeBytes property to ImageCesium, so that its size can be tracked even after pixelData has been cleared (such as in CesiumGS/cesium-unreal#1330.

This is a little hacky. Arguably this information should be stored somewhere else, such as is in the Tile and/or RasterOverlayTile. But putting it here keeps things simpler, particularly around thread safety. In CesiumGS/cesium-unreal#1330, the pixel data is cleared in the worker thread. But worker threads, by design, don't have access to Tile or RasterOveralyTile. So it all gets very elaborate, and hard to justify.

Copy link
Contributor

@csciguy8 csciguy8 left a comment

Choose a reason for hiding this comment

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

Look good @kring .

Tested this in Unreal and the new code executes just fine.

Just a couple of suggestions before I merge:

  • The new member is called sizeBytes. Would a name like lastKnownSizeBytes by a bit more descriptive?
  • How do you feel about making it a std::optional instead of using -1 to indicate not set yet?

@j9liu
Copy link
Contributor

j9liu commented Feb 21, 2024

The new member is called sizeBytes. Would a name like lastKnownSizeBytes by a bit more descriptive?

If we're nitpicking names, could I suggest rewording it to sizeInBytes or byteSize? 😄

@csciguy8
Copy link
Contributor

@j9liu Split the difference, it is now lastKnownSizeInBytes

@csciguy8 csciguy8 merged commit 028fc7c into main Feb 23, 2024
14 checks passed
@csciguy8 csciguy8 deleted the image-size-bytes branch February 23, 2024 18:02
@csciguy8
Copy link
Contributor

This looks good to go, merged.

Thanks @kring !

@kring
Copy link
Member Author

kring commented Feb 24, 2024

No need to change it, lastKnownSizeInBytes is a good enough name. But I think sizeBytes is also fine, perhaps a little better. The reason is that "descriptor + units" is a common naming convention used all over. See Cartographic: longitudeDegrees, heightMeters. Perhaps degreesLongitude and metersHeight would be better? It's a bit of a bike shed, but I don't think so. For one thing, bytesSize and degreeLongitude both sound awkward, so should the units be singular or plural? More importantly, putting the most important bit first (longitude, height, size) slightly improves discoverability and auto-completion experience.

As for "last known", well, that's fine I guess. It comes back to my statement at the top of this PR that this a bit hacky. It's really the size for caching purposes.

Like I said, no need to change anything, just wanted to share my thought process on this.

@j9liu
Copy link
Contributor

j9liu commented Feb 26, 2024

The reason is that "descriptor + units" is a common naming convention used all over.

I have a bit of a gripe with this formatting too! 😅 But no need to change it when it's already widely used. I still prefer sizeBytes over lastKnownSizeInBytes. If it's okay, I'd rather push a commit to main to undo the name change

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.

None yet

3 participants