View Issue Details

IDProjectCategoryView StatusLast Update
0008424ardourbugspublic2020-09-27 13:46
Reporteralightalike Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
PlatformArchOSLinuxOS Version(any)
Summary0008424: why does ardour re-compute the bitmap for each wave file whenever it shows up on screen instead of whenever the file changes?
DescriptionI don't have much to add from the summary. I can fix this myself but I would have to learn the code. Y'all know the code already. Please fix.
Steps To Reproducescroll
Additional Informationn/a
TagsNo tags attached.

Activities

alightalike

2020-09-27 13:34

reporter   ~0025067

if I am wrong about this or **if y'all can't use this information to fix scrolling easily** please let me know it and I can learn the code so I can fix whatever the problem really is. I'm sure i can make the scroll/graphics display code run so much more smoothly. there is no good reason for scrolling to take so much time; some process must be running unnecessarily. the bitmaps for the whole session at a given zoom level can be "printed" to ram once and left there unless they need to be reprinted (if the file changes or if zoom changes).

alightalike

2020-09-27 13:43

reporter   ~0025068

there is no good reason for scrolling to take so much time (in my use case) I should say. for people who actually use zooming regularly it might be better the way it is. can y'all make this a setting at least? or do I just need to mod it myself?

alightalike

2020-09-27 13:46

reporter   ~0025069

what if the first time a bitmap is drawn at a zoom level it processes? like make the bitmap a member class of the track class with a flag for zoom that draws if the correct bitmap for the track doesn't exist? would that work?

Issue History

Date Modified Username Field Change
2020-09-27 03:37 alightalike New Issue
2020-09-27 13:34 alightalike Note Added: 0025067
2020-09-27 13:43 alightalike Note Added: 0025068
2020-09-27 13:46 alightalike Note Added: 0025069