Imgui: Question: are you rendering with Nearest texture filtering? (instead of Bilinear)

Created on 10 Jan 2020  路  9Comments  路  Source: ocornut/imgui

Hello,

Dear ImGui can technically be rendered with the texture unit configured to use Nearest sampling instead of Bilinear. All examples and provided backends have been using Bilinear, which allows for oversampling of fonts, some (not ideal) degree of font scaling, and generally more convenient when rendering user images.

Question: Are you rendering Dear ImGui using Nearest filter, and why?
If you use it, do you use it for all your Dear ImGui rendering, or only temporarily (e.g. when doing a certain ImGui::Image() call). Do you ever render part of the Atlas texture (which is used by ImDrawList shape) using Nearest filtering?

Some reasons I can think of:

  • A) Using a software renderer
  • B) Rendering on very low spec gpu/machine (please specify)
  • C) Trying to achieve a certain look intentionally (please specify)
  • D) Switching to nearest filter temporarily (via a ImDrawCallback) to blit 1:1 image data faster.

Reason is we're looking into making changes to the ImDrawList rendering primitives that would require Bilinear filtering of the texture to render shapes. That potential change would still allow D to work but would potentially make things harder for A,B,C.

Please note that the problem only applies if Nearest filtering is used when drawing ImDrawList shapes such as borders, rectangles, anti-aliasing lines, circles etc.

Based on your feedback we could decide on the best solution or workaround (e.g. provide a runtime flag, vs provide a compile-time flag, vs ditch that support alltogether?).

Thanks.

PS: If you are using one of the imgui_impl_xxx backend without modification, you are using Bilinear filtering.

backenbinding drawindrawlist question

Most helpful comment

Hello!
I work on a spritesheet editor whose main use case it to manage pixel-art game sprites. Rendering the sprites with nearest neighbor filtering is crucial for them to look good when scaled (by integer zoom factors). Project: https://github.com/agersant/tiger/

I think that puts me under "C) Trying to achieve a certain look intentionally"

screenshot-0 2 0

All 9 comments

Hello!
I work on a spritesheet editor whose main use case it to manage pixel-art game sprites. Rendering the sprites with nearest neighbor filtering is crucial for them to look good when scaled (by integer zoom factors). Project: https://github.com/agersant/tiger/

I think that puts me under "C) Trying to achieve a certain look intentionally"

screenshot-0 2 0

EDIT Not applicable (see clarification below).

Option C.

I'm using the nearest neighbor filter in order to be able to zoom in on small textures. My textures are weights in a neural network, thus the necessity to be able to distinguish the individual pixels/values.

image

I need to clarify the question above into:
" do you use Nearest texture filtering in a draw command using the Atlas texture created and used by ImDrawList shapes (rectangles, borders, fonts) "
In many graphics api filtering is exposed as a property of the texture it seems like a natural path for many to keep using bilinear for dear imgui's atlas while using nearest for other textures.

EDIT (this is actually important)
Do you set it up with a callback or it is a permanent all-frame setup?

I'm fairly sure I've used nearest pixel on macOS retina displays to make UI look crisp while drawing it scaled up. I'm not on the cutting edge version of imgui, so maybe this isn't relevant anymore.

I've set Dear ImGui's Atlas texture to be drawn with Nearest filtering because I also draw my engine's text using Nearest to avoid some rendering issues that are most likely my fault, but in practice, as long as I don't manipulate ImGui's font scale, I could as well set it to bilinear.

Aside from nearest filtering some user textures (like in my image editor to keep zoomed pixels square), the only reason I use it on the main texture atlas is when I use the default Dear ImGui embedded font, because when I zoom it, I think it looks better this way (less blurring on the already blocky font).

As far as I remember there was no other reason for not using a better texture filtering...
Probably having a better quality embedded font would help.

Thank you everyone for your answers on this!

Generally no, but I do round coordinates before calling DrawRect to render non-antialiased horizontal/vertical lines on a scaled overlay to prevent it looking blury.

Closing this as answered, thank you all!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DarkLinux picture DarkLinux  路  3Comments

bizehao picture bizehao  路  3Comments

BlackWatersInc picture BlackWatersInc  路  3Comments

GrammarLord picture GrammarLord  路  3Comments

dowit picture dowit  路  3Comments