EmbarkStudios/puffin

Remove support for imgui?

Closed this issue · 6 comments

repi commented

At Embark we have, quite a while back, moved fully over to egui and we are not too interested in maintaining the imgui version of the puffin viewer here, and there are no public users of it either (https://crates.io/crates/puffin-imgui/reverse_dependencies).

So think we can simply remove the code for it and focus only on the egui version from now on, older published versions of the crate will still ofc be available on crates.io.

Also note that we are on an old version of imgui (0.10, not 0.11)

Thoughts @TimonPost @emilk ?

repi commented

there is a known issue with the imgui support also that we were running into ourselves when we had it (assert in the imgui C code so likely lack of validation in imgui-rs):

So seems to be one recent user of the imgui version of puffin at least from that issue (@Danvil). but don't think we can maintain something we don't use ourselves

repi commented

Also @aclysma 's profiling crate uses the imgui version of puffin as a dev-dependency (https://github.com/aclysma/profiling/blob/master/Cargo.toml), but with some work could likely be switched to the egui version separately for future versions of that.

Danvil commented

Hello, yes I am using imgui-rs for a project, but I don't have the bandwidth to take over maintance for puffin/imgui. Thank for all the great work on puffin!

The implementation of Imgui is currently lagging behind the egui implementation, and any new features developed for egui require additional effort and time to be ported to Imgui which I personally have not been doing for that reason. It appears that Imgui implementation is no longer actively maintained, although completely removing the code might be too extreme. One potential solution could be to exclude it from the cargo release process and instead manually update versions and dependencies based on incoming pull requests when people are really interested in it. Or potentially give ownership to someone who actively uses it. Perhaps the imgui project?

Determining the extent of professional or personal usage of Imgui is challenging. For small personal projects, it seems unlikely that there would be a compelling reason to use Imgui at this stage, as a pure Rust alternative is likely sufficient for their needs. However, in larger companies or other contexts where Imgui is extensively used, they might have the resources and capability to contribute to updating dependencies and seeking support if necessary.

TLDR my two cents:

  • Perhaps propose ownership to imgui-rs project
  • Do an open proposal for if there is a company that uses imgui impl to get ownership
  • Update project README to state its not actively maintained but PR's are accepted, and remove imgui from the release process.
repi commented

if there were known major users that are interested in keep using it and want to support and maintain it, then I think all of your steps would be reasonable. but there are 0 direct users in public crates and only one crate profiling / ambient-profiling that is using it, so I think we should just simplify our own maintenance and fully remove the support, it is not worth spending our time on.

And then if there is someone that wants to revive it and take it over, then they can post in this issue to coordinate that and revive it from an older revision and move it to another repo.

we have an agenda of our own to support egui that we use, and that is native Rust, rather than imgui that we do not use and is a non-native dependency with quite a few issues that we've run into over the years.

so let's just nuke it!

Danvil commented

Just wanted to mention that I switched to egui. It was mostly painless and also allowed me to upgrade to latest versions of puffin, wgpu and winit.