Give users control over the texture filter

[mccolljr]

Is your feature request related to a problem? Please describe.

I wanted to utilize the Painter::set_texture_filter feature that was recently introduced to egui_glow, but the only way to do so is by breaking out of eframe and calling into egui_glow directly. This... involves a lot of manual reconstruction of code that is difficult to get right, especially for someone newer to this type of programming

Edit: Per discussion below, it seems more accurate to say that I'd like to be able to specify the texture filter on a per-texture basis.

Describe the solution you'd like

Some sort of mechanism to pass backend-specific configuration tweaks via eframe. This could be as simple as adding a function alongside run_native for that each relevant backend, perhaps run_native_with_options? I don't want to prescribe a specific implementation here because I am so new to this library - I don't know what the long term goals are for eframe, or how this concept might interact with them.

Describe alternatives you've considered

1. Don't do this - just point people towards the examples and let them copy the code that they need. This is the current state of the world and it is functional, but not very ergonimic
2. Add cfg-gated options to NativeOptions in epi. This feels dirty to me
3. Approach this from a different angle and define PainterOptions in epi, which could provide a backend-agnostic way to set some global properties of the painter implemented by the backend. This seems like it could get complicated and there is a question of what to do if an option is provided that the backend in question can't actually handle.

[emilk]

I think texture filtering in particular could be part of the new epaint::TextureManager API instead, though we need to be careful not to add too much complexity to what is supposed to be a simple 2D painting API (more advanced painting should always be done with something outside of egui, e.g. bevy)

[mccolljr]

This seems like it would work, as well!

For context - I am working on some pixel drawing functionality in an app, and I would like to support canvas sizes up to 1024x1024 pixels. The current approach of rendering the image to a mesh where each pixel is a rectangle scaled to the chosen zoom level is not performant once the visible area approaches 512x512 logical "pixels". I have had better results rendering a single rectangle with the appropriate texture uv, but for this to look pixel-perfect I utilize the NEAREST filter. So for my purposes, a single global setting is sufficient.

Perhaps this could be provided as a pub filter: SomeTextureFilterEnum on TextureDelta?

[mccolljr]

I've played with an implementation of the above to get a feel for what the API surface might look like, and I noticed that much of the code that handles textures applies the texture filter on a per-texture basis to begin with.

Maybe it makes sense to allow a filter property on the textures themselves. This would mean that the TexturesDelta struct would need to store a little more than just ImageDelta data for each texture, but it seems achievable. I can see valid reasons for either level of granularity so I'm curious what you think.

[mccolljr]

I created a proof of concept here: https://github.com/emilk/egui/pull/1296/files

For my use case, this sample implementation using the per-texture approach turned out to be useful. I'm able to choose "linear" when the zoom is < 1.0 and "nearest" when the scale is >= 1.0.

I tried both - setting TextureFilter at the TexturesDelta level (applies to all textures) as well as at the individual texture level. When I tried setting the texture filter at the top level, it was difficult to get the behavior consistent between glium and glow - glium binds the filter at draw time, but glow+web bind the filter when the texture is loaded. I felt like ergonomics were a little better at the per-texture level, but I'm still not in love with the API. Still, I thought a sample implementation might make it easier to collectively reason about how this should look (or if it should be done at all)

[emilk]

Closed by #1636