Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opaque/On-Demand Data #3869

Open
daxpedda opened this issue Aug 14, 2024 · 2 comments
Open

Opaque/On-Demand Data #3869

daxpedda opened this issue Aug 14, 2024 · 2 comments
Labels
C - needs discussion Direction must be ironed out S - api Design and usability

Comments

@daxpedda
Copy link
Member

Currently we deliver all available data in events to the user and our types are accordingly composed: pub struct Data { pub data_1: ..., ... }. However sometimes users just don't need all the data and especially when we implement #99 a lot of data (number of things, not size) has to be assembled by the backend.

This can sometimes involve multiple callback per field which might be computationally expensive if the user doesn't need all the information.
This proposal aims to reduce the impact of this issue by turning delivered events into opaque types where users can query the data they need individually.

The opaque type will most likely have to carry some state with it that will come with a lifetime, so the data can probably not be transferred to a different thread or out of the event loop in a complete package. This will further increase the cost of moving to the trait-based system and the elimination of the Event type.

Most likely it would make much more sense to discuss/implement this proposal when we have fully switched to the trait-based system and Event/WindowEvent doesn't exist anymore.

@daxpedda daxpedda added S - api Design and usability C - needs discussion Direction must be ironed out labels Aug 14, 2024
@madsmtm
Copy link
Member

madsmtm commented Aug 14, 2024

I'm in favour of the proposal, but yeah, let's wait until after the dust have settled a bit on all the other refactorings

@kchibisov
Copy link
Member

Most likely it would make much more sense to discuss/implement this proposal when we have fully switched to the trait-based system and Event/WindowEvent doesn't exist anymore.

I agree, since the most straightforward and easy to use thing is to pass a e.g. &mut Keymap along the event, so the user can build what they want with it and change it the way they want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs discussion Direction must be ironed out S - api Design and usability
Development

No branches or pull requests

3 participants