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
Fix multiple partial updates of the same texture #1338
Conversation
epaint/src/textures.rs
Outdated
@@ -150,7 +153,7 @@ impl TextureMeta { | |||
#[must_use = "The painter must take care of this"] | |||
pub struct TexturesDelta { | |||
/// New or changed textures. Apply before painting. | |||
pub set: AHashMap<TextureId, ImageDelta>, | |||
pub set: AHashMap<TextureId, Vec<ImageDelta>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be even simpler to just make this a Vec<(TextureId, ImageDelta)>
? I don't really see the point of having it be a hashmap anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent suggestion. That avoids the double allocations. However, we would then always push to the end, and pop the front, like a FIFO, right? If so, maybe using a VecDequeue
would be clever? On the other hand, we always consume the full Vec
at once when we consume it, so using into_iter()
will probably be even more efficient than the VecDequeue
, then again. Does into_iter()
on a normal vector cause any de-allocations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A Vec
is the best fit since we always push to the back and consume the whole thing with either std::mem::take
or drain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really see the point of having it be a hashmap anymore.
On argument for this: we can remove all deltas accumulated when a full update is received for a specific id. However this is quite insane API usage, requesting multiple changes of the same image only to toss it completely later on by a full update.
I think we should make it a |
7e92f56
to
b9b7192
Compare
@emilk Sorry for the long delay. I just applied your (execellent!) suggestion, and rebased. Let's see what the CI says 😄 |
6b53b6f
to
7197fb5
Compare
Oof. |
In case of a whole update we want to ignore all previous updates, so I suggest simply: self.delta.set.retain(|(x, _)| x != id);
self.delta.set.push((id, delta)); |
introduces a queue for texture changes
@emilk Please take a look again :) |
Co-authored-by: Wanja Zaeske <wanja.zaeske@dlr.de> Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Co-authored-by: Wanja Zaeske <wanja.zaeske@dlr.de> Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
introduces a queue for texture changes
Closes #1337.