circleguard / circlevis

A (Py)Qt widget for visualizing osu! beatmaps and replays
GNU Affero General Public License v3.0
7 stars 1 forks source link

hitobject stacking is cached too aggressively #15

Open tybug opened 3 years ago

tybug commented 3 years ago

when visualizing a non-HR replay and then a HR replay on the same map, the stacking uses the non HR version instead of the HR version. Reproduction:

from circleguard import *
from circlevis import *

cg = Circleguard("key",
    db_path="/Users/tybug/Library/Application Support/cache/circleguard.db",
    slider_dir="/Users/tybug/Library/Application Support/cache/")

from PyQt5.QtWidgets import QApplication
app = QApplication([])
app.setStyle("Fusion")
app.setApplicationName("Circleguard")

r = cg.Map(2102290, "1", mods=Mod.HD, load=True)[0]
bm = BeatmapInfo(map_id=r.map_id)
vis = Visualizer(bm, [r], library=cg.library)
vis.show()
app.exec()

r = cg.Map(2102290, "5", mods=Mod.HDHR, load=True)[0]
bm = BeatmapInfo(map_id=r.map_id)
vis = Visualizer(bm, [r], library=cg.library)
vis.show()
app.exec()

the hitobjects at t=10882 stack from the bottom when they should stack from the top on the second replay visualization.

The following patch to slider fixes this:

diff --git a/slider/library.py b/slider/library.py
index 043e192..0af417e 100644
--- a/slider/library.py
+++ b/slider/library.py
@@ -290,6 +290,7 @@ class Library:
             Raised when the given id is not in the library.
         """
         try:
+            self._read_beatmap.cache_clear()
             return self._read_beatmap(self, beatmap_id=beatmap_id)
         except KeyError:
             if not download:
@@ -314,6 +315,7 @@ class Library:
         KeyError
             Raised when the given md5 hash is not in the library.
         """
+        self._read_beatmap.cache_clear()
         return self._read_beatmap(self, beatmap_md5=beatmap_md5)

     def beatmap_from_path(self, path, copy=False):

but this is obviously not a solution. I'm sure what the root cause is yet. It doesn't seem to be an issue with the actual stacking calculation caching, as that cache is hit properly when it needs to be as far as I can tell.