Skip to content

Prioritize visual requests over data requests #706

@ShaMan123

Description

@ShaMan123

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureSomething new that we could do

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions