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
The FFT calculation + pixmap generation really needs to be pushed out of the UI thread.
I'm thinking something like this:
paintEvent figures out what tiles it needs to display, loops through requesting from the cache and displaying them.
On a cache miss, that tile ID is added to a job list.
Worker thread(s) pop a job off the list, do the processing, then insert FFT results & pixmap data into the cache.
Once a new tile is done, call invalidate() on that area and paintEvent should run again.
A long scroll on a slow machine could queue up a lot of jobs, including ones are way out of view once the scrolling is done. I'm thinking the jobs should be processed by most recent first, then the job list should be limited in length with older jobs being discarded.
As a future addon I want to be able to peek ahead and start processing nearby tiles ready to be shown. Just adding these to the end of the job list if there's space should work (they should not be higher priority than jobs for the current view).
The text was updated successfully, but these errors were encountered:
The FFT calculation + pixmap generation really needs to be pushed out of the UI thread.
I'm thinking something like this:
A long scroll on a slow machine could queue up a lot of jobs, including ones are way out of view once the scrolling is done. I'm thinking the jobs should be processed by most recent first, then the job list should be limited in length with older jobs being discarded.
As a future addon I want to be able to peek ahead and start processing nearby tiles ready to be shown. Just adding these to the end of the job list if there's space should work (they should not be higher priority than jobs for the current view).
The text was updated successfully, but these errors were encountered: