Introduce IMGUI_USE_BGRA_PACKED_COLOR in imconfig.h.

[thedmd]

PR adds ability to tell ImGui to generate packed color in BGRA format instead of RGBA.
This change simplify backend implementation by removing need to convert colors in vertex buffer before uploading to engine. For ImGui packing colors differently make no difference and backend can use memcpy().

To change color packing uncomment #define IMGUI_USE_BGRA_PACKED_COLOR in imconfig.h

What changes. Hardcoded bit shifts were replaced by constants like IM_COL32_R_SHIFT. Depending of IMGUI_USE_BGRA_PACKED_COLOR being defined constants have different values.

[ratchetfreak]

Or you could change the vertex shader to do a color_out = color_in.bgra; instead of a color_out = color_in;

This will still allow use of memcpy in the backend.

[thedmd]

@ratchetfreak In example application I can, but in engine I have no direct access to shaders. Yet, there may be no shaders at all and renderer may use fixed pipeline. This feature is handy in real world use when control over what you can change is limited.

[ocornut]

@thedmd Have you measure the cost of your RGBA>BGRA conversion loop at the end of the render? Is it actually meaningful?

Patch feedback

• The macro IM_COL32_BLACK becomes wrong.
• There's code in ImGui::Render that uses hardcoded hex values needs to be changed to use IM_COL32()
• ValueColor() needs to be updated?

[thedmd]

@ocornut No, I did not. I think it is very unlikely my conversion loop will get anywhere close to memcpy performance without committing many hours in utilization of processor extensions. But that is aftermath.
Real issue was not copying but format of packed color ImGui output. Engine I use is expecting different one and I cannot change that. If I can bend middle-ware to fit better I will try to do so to avoid having problem in the first place.

What is your opinion?

[ocornut]

it is very unlikely my conversion loop will get anywhere close to memcpy

My question is have you ever measured the cost of your naive conversion loop?
We are talking about ~10k mostly contiguous vertices which is a small amount. Even a naive conversion shouldn't take much time.

[thedmd]

No, I didn't. Motivation was to avoid need of doing conversion, not to speed up copying.

[thedmd]

PR was recreated due to lost references after changing fork origin. That was not my intention, sorry.
Updated PR.