Support 8-bit (s)RGBA BLImages?

[LunaTheFoxgirl]

Some APIs do not expose an ARGB format, and as such having to flip the order to fit can be a relatively intensive task.
Would it be in the cards to add a 32-bit RGBA and 128 bit RGBA (4x floats) BLFormat which allows for easier interop with, for example, 3D graphics APIs?

[kobalicek]

Having multiple formats targeting 32-bit images is something I considered in the past, and it's still in consideration, but it's also something that could make Blend2D binaries much bigger, because all the additional pixel formats would need to be handled by JIT and portable pipelines. Basically each new pixel format contributes to existing pipelines as it has to be handled by texture fetchers, and since Blend2D doesn't use intermediate buffers in pipeline stages it has to be inlined - that's the main reason Blend2D doesn't offer rich pixel formats at the moment.

I would keep this in consideration, but it's something that would definitely not happen overnight, it would be quite a lot of work to implement additional pixel formats.

BTW There is BLPixelConverter to deal with this, which is optimized for converting pixels, but I agree that it's still an overhead.

[qd1308504206]

I also strongly support this suggestion. Currently, after using Blend2D to read images, we get a BGRA sequence, but I realy want the RGBA sequence. This is related to many software usage issues, such as texture images in 3D rendering. @kobalicek

[kobalicek]

@qd1308504206 I would gladly review a PR implementing this, but I have different priorities at the moment - AArch64, stroking, and clipping+layers. So if anyone would like to contribute more pixel formats I'm okay with that, I would gladly mentor such a contribution.

[LunaTheFoxgirl]

I may look in to creating such a PR when I get time, then.

[kobalicek]

BTW for the purpose of interacting with different pixel formats, be it IO or something else, Blend2D offers BLPixelConverter - that specializes in converting from one pixel format to another and optimizes the cases by using SIMD. In general this was the solution to use only limited set of pixel formats for rendering and BLPixelConverter for talking to outside world.

I personally don't have an issue with the current pixel format - it seems majority of other 2D libraries offer at least exactly this pixel format, be it Qt, Skia, AGG, and other libraries, so for me this was never an issue.