-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Eliminate redundant transformations when drawing WCSAxes ticks/gridlines #16362
Comments
Thanks for the diagnosis! I think the main thing to figure out is how to determine if the transform has changed compared to a previous call, i.e. how to determine the key for the hash. We might also want to see if it would be easier to do the caching at the |
One of the main difficulties with caching is going to be knowing if the WCS has changed in any way. For FITS WCS, If we can't figure this out, then the next best option will be to have some way in WCSAxes of temporarily setting some kind of context within which the four transformation will happen and assuming that within that context the WCS won't get modified (which is reasonable). We might need to do this because we will probably need to assume within this that the coordinate transformation graph doesn't get modified. |
Ooh, that's a simple solution. The four transformations are actually all tightly grouped in the following loop ( astropy/astropy/visualization/wcsaxes/core.py Lines 508 to 509 in 835f64f
It should be straightforward to compute the coord range once before this loop and then have everything within utilize the same output. Draft PR incoming! |
#16366 solves the immediate issue by reducing the four transformations to just one. It doesn't do anything for redundant transformations if |
What is the problem this feature will solve?
When WCSAxes draws ticks/gridlines, it performs a pixel->world transform of (by default) a 50x50 grid of pixels, but it currently performs the identical calculation a total of four times: once when drawing ticks, again when drawing gridlines, and doubled because there are two components. These redundant calculations are particularly expensive when working with grid overlays (world->world) because then the coordinates framework is being used.
Describe the desired outcome
Caching should be implemented so that the pixel->world transform is recomputed only when necessary.
Additional context
Both
CoordinateHelper._update_ticks()
andCoordinateHelper._update_grid_lines()
callCoordinatesMap.get_coord_range()
, which in turn callsastropy.visualization.wcsaxes.coordinate_range.find_coordinate_range()
. Unfortunately, there is no caching of the output offind_coordinate_range()
.The text was updated successfully, but these errors were encountered: