-
Notifications
You must be signed in to change notification settings - Fork 190
Description
Description 📝
I am working on a viewer that has 2 main aspects: displaying and interacting with the model and displaying related data (I guess all viewers can be said to do that).
I noticed that data requests (e.g. query property sets) block visual requests (e.g. zoom, highlight) and slow down my app.
Ideally I would like the threaded model to have a mechanism such that the data requests would not block the visual requests, as the visual requests have higher priority in order to provide good UX.
I would also like to have abortable requests. e.g. I have a long scrollable list, I fetch data from the model according to the visible scroll range. When the scroll changes I would like to abort the related data requests and fetch relevant data. Currently it seems that the new requests need to wait for the irrelevant requests to complete, making UX suboptimal. Not sure how easy this will be to implement.
I do not know the inner workings of the threaded model unfortunately so I might be totally off here.
Suggested solution 💡
2 queues for visual/data requests or a way to control the queue's order (prepend a request).
Or perhaps 2 queues for readonly/write requests, the readonly queue can be stalled by the write queue.
Alternative ⛕
I am maintaining a queue on my side, I can enlarge its scope to include this.
Additional context ☝️
No response
Validations ✅
- Read the docs.
- Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.