You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are three places where I think caching could be appropriate:
GDALDatasets in the extractors. The overhead of opening a dataset is relatively small and we'd have to check Assess thread safety, make as thread safe as possible #10 first, but with many texture loads per second, there would likely be an improvement.
Return values of core Geodot functions like Geodot.get_image. It's plausible that these functions are called with the same arguments multiple times (e.g. to load the same heightmap for the terrain and for the collider in two different places) and this would greatly reduce the cost of consecutive calls.
Return values of geodata-class-to-Godot-object functions such as GeoImage.get_image_texture or GeoLine.get_curve3d. These tend to do quite a lot of work for converting the raw C++ data to a Godot class.
In some cases, we'd have to decide whether we want to return exactly the same object or a copy of the previously computed object.
The text was updated successfully, but these errors were encountered:
There are three places where I think caching could be appropriate:
Geodot.get_image
. It's plausible that these functions are called with the same arguments multiple times (e.g. to load the same heightmap for the terrain and for the collider in two different places) and this would greatly reduce the cost of consecutive calls.GeoImage.get_image_texture
orGeoLine.get_curve3d
. These tend to do quite a lot of work for converting the raw C++ data to a Godot class.In some cases, we'd have to decide whether we want to return exactly the same object or a copy of the previously computed object.
The text was updated successfully, but these errors were encountered: