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

Enhance performance of color_image_as_bevy_image #334

Open
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

gogo2077
Copy link

#283
Before
1734022939999
After
1734022425213

@vladbat00
Copy link
Owner

vladbat00 commented Dec 15, 2024

Hi, thanks for the PR! This is a good improvement, but I think I'd rather have this optimisation upstreamed to ecolor so that we can keep using their implementation and avoid adding other dependencies (even though quite a lightweight one). How do you feel about contributing this directly to Egui's ecolor instead?

Btw, even 33ms looks like a lot.. What's the size of the image you are trying to update? This made me think whether offloading the conversion to a separate task pool would make sense. (Not sure it would make any difference in WASM though...)

Or we can look into implementing a partial image update if that can help in your scenario.

@gogo2077
Copy link
Author

Hi, thanks for the PR! This is a good improvement, but I think I'd rather have this optimisation upstreamed to ecolor so that we can keep using their implementation and avoid adding other dependencies (even though quite a lightweight one). How do you feel about contributing this directly to Egui's ecolor instead?

Btw, even 33ms looks like a lot.. What's the size of the image you are trying to update? This made me think whether offloading the conversion to a separate task pool would make sense. (Not sure it would make any difference in WASM though...)

Or we can look into implementing a partial image update if that can help in your scenario.

Hi, thanks for the PR! This is a good improvement, but I think I'd rather have this optimisation upstreamed to ecolor so that we can keep using their implementation and avoid adding other dependencies (even though quite a lightweight one). How do you feel about contributing this directly to Egui's ecolor instead?

Btw, even 33ms looks like a lot.. What's the size of the image you are trying to update? This made me think whether offloading the conversion to a separate task pool would make sense. (Not sure it would make any difference in WASM though...)

Or we can look into implementing a partial image update if that can help in your scenario.

Hello, I’m not very familiar with egui, but I can give it a try.

I’m developing a card game where individual images aren’t very large, but there might be a lot of images and fonts created all at once.

vladbat00 and others added 20 commits December 22, 2024 01:47
* Capture pointer when used with bevy_picking

This fixes "clicking through" egui when using bevy_picking

Co-authored-by: Robin Gloster <[email protected]>

* Gate bevy_picking support behind the render feature

* Fix the linux dependencies documentation

---------

Co-authored-by: Aevyrie <[email protected]>
Co-authored-by: Robin Gloster <[email protected]>
* Refactor input systems (closes vladbat00#173)

* Add color_test example

* Add support for redirecting events to non-window contexts

* Actually respect EguiGlobalSettings

* Remove web_sys_unstable_apis, fix docs and tests

* Fix windows build

* Disable the headless test (broken after a Bevy update)
* Make input systems disable-able

* Fix the docs
…thub.com:gogo2077/bevy_egui into Enhance-performance-of-color_image_as_bevy_image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants