How to switch from 16bit to 32bit colors

[AntumArk]

Hello there!

I am currently working with a project which uses 2018-2019 year old modified branch ( unfortunately history is lost there... ) v0.93 I require to switch from using 16bit color scheme to 24bit. In principle only changing config file and rebuilding should be needed? Or is there something else that needs to be handled? My project uses prebuilt nano-X (screen X11) and some of the headers.

[ghaerr]

Hello @AntumArk,

Microwindows (usually) has support for all color schemes compiled in, and allows for switching at run-time, depending on the query results from the framebuffer driver or X11. Thus, depending on your setup, no reconfiguration may be needed, except for the target display itself. However, if the application(s) read or write screen or offscreen bitmap data directly, that format is specified separately, and may need porting. But in general, if Nano-X is just drawing using the NX API, things should just work.

Lets keep this issue open, and I'll help with more details as you find them.

Thank you!

[AntumArk]

I will update on this tomorrow. But from what I am seeing, that feeding 24bit colors to the screen still produces 16bit colors. Tried multiple modes (0888,8888,ARGB) and got some mess... Although ABGR at least looked not glitchy xD. I will add some snippets later.

[ghaerr]

feeding 24bit colors to the screen still produces 16bit colors.

You have to match the Nano-X pixel color format with the screen pixel format, "sending" 24-bits to a 16-bt display will never work, or vice versa. Nano-X normally handles this automatically, by querying the display. So we need to start by understanding exactly what your display expects, then determining whether Nano-X is compiled to handle that format.

Tried multiple modes (0888,8888,ARGB)

Setting this in the config file doesn't change the query function above, that is, it doesn't necessarily force a certain pixel format, only a default format in other operations. Please specify exactly what display (FB, X11 etc) type you are running and the pixel format desired. Since it sounds like you you're changing from 16 to 24 bit display, describing the previous display might also help us solve this problem.

[AntumArk]

So, here is how generally throughout the code draw operations are done:

#define MWPF_USED_COLOR_MODEL         MWPF_TRUECOLORARGB

GR_PIXELVAL * const targetbuffer  = static_cast <GR_PIXELVAL*> (malloc( numberOfPixels * sizeof(GR_PIXELVAL) ));
GrArea (static_cast<GR_DRAW_ID>(Bitmaps[BitmapNr]->WinID), GcID, 0, 0, BITMAPBREITE(BitmapNr), BITMAPHOEHE(BitmapNr), targetbuffer, MWPF_USED_COLOR_MODEL);

As for determening screen type, where should I look for that setting? I am not working with physical machine though.

[ghaerr]

So, here is how generally throughout the code draw operations are done:

I see now, thanks. This code uses the latter method as I discussed above. It uses a constant 32-bit ARGB pixel ordering of data from your application, which when passed to GrArea should be converted to the actual screen pixel format. I would think that this section of code does not need modification, but instead possibly GrArea may not be converting the ARGB pixel format properly.

I suppose I don't fully understand your issue - does the code work on previous hardware and now you're porting to a new system, and it displays incorrectly? This issue title discusses 24 bit color, but the application is actually passing 32 bit color pixels to GrArea. What exactly is the problem you are seeing and trying to solve? Perhaps you can post pictures of a working and non-working system?

As for determening screen type, where should I look for that setting? I am not working with physical machine though.

I don't even know what the output display type is, as I asked for previously. Is this on X11 or frame buffer? I need more information to understand. If you're running on an emulator, what is the screen configuration set to?

Thank you!

[AntumArk]

Thanks for the reply!

I suppose I don't fully understand your issue - does the code work on previous hardware and now you're porting to a new system, and it displays incorrectly?

So, we are working in two teams( hardware team and me) in porting old machine (linux) and emulator (windows, my part) which used 16bit framebuffer to a new 32bit monitor and emulator. The emulator is working on 16 bit framebuffer _MWPFTRUECOLOR565

Perhaps you can post pictures of a working and non-working system?

The needed result:

Actual result:

And the new machine is working well on 32 bit buffer.

This issue title discusses 24 bit color, but the application is actually passing 32 bit color pixels to GrArea.

I am sorry about the confusion for 24bit. A lot of the code including how the emulator is configured is a black box to me as I am trying to figure this out. Why I am saying 24bit, is because alpha channel is used in (i think) not standard way, where are two specific colors which handle transparent areas. I am yet sure about the specifics on how it is done. Also there is a possibility that hardware team is using newer or highly modified version of NanoX, but they are really slow at responding to my queries, so I am still waiting for their answer on this which should really make it clearer. So don't worry if some info may seem vague 😄 .

I don't even know what the output display type is, as I asked for previously. Is this on X11 or frame buffer? I need more information to understand. If you're running on an emulator, what is the screen configuration set to?

In config file, it is X11.

I hope that clears it up a bit more 😊

[ghaerr]

because alpha channel is used in (i think) not standard way, where are two specific colors which handle transparent areas.

Ah, this could very well be an issue. Nano-X may be doing its own math on the RGB colors (using alpha-blending) based on the Alpha value. Or, the X11 screen driver/X11 could be doing something. The config file should probably still use MWPF_TRUECOLORARGB, as that sets sizeof(GR_PIXELVAL) in your code above.

I would need more information on whether you need the alpha value passed through to the hardware or not to take next step.

If, on the other hand, your older system used MWPF_COLOR_MODEL as MWPF_TRUECOLOR565 (which is 16-bit), then that means the application is passing 16-bit values to Nano-X.

You must ensure that the application supplies the proper pixel values and matches the parameter passed to GrArea. I hope this helps.

Also there is a possibility that hardware team is using newer or highly modified version of NanoX

Well, that's going to introduce all sorts of other issues.

In config file, it is X11.

That Nano-X X11 screen driver should display onto stdout what BPP and color format is being used. If not, set DEBUG=Y and recompile.

With the application producing one set of pixel formats, then passing them to GrArea with its specified pixel format parameter, then Nano-X possibly converting that into what it thinks the screen format is, then possibly having the X11 screen driver do another conversion, there are lots of variables here.

However, looking at your screenshots, it seems that the basic drawing is correct - so I would guess that the special alpha value being passed to the hardware could be an issue here, since that value wasn't used in 16-bit but is being used (passed through) for 32-bit color. You could look further into the X11 screen driver at drivers/scr_x11.c and look for the MWPF_TRUECOLORARGB (or 8888) case(s) and force alpha=255 to see if that helps.

[AntumArk]

Actually how do you compile for windows? I was only able to compile for linux.

[ghaerr]

Actually how do you compile for windows?

That's not supported by myself, since I don't have a Windows box anymore. But there are a couple Visual Studio projects in contrib/ports/visualstudio and contrib/ports/vs2008 you might look at. They are likely out of date and may need some filename changes.

[AntumArk]

So I have found the custom makefile for Windows from previous employee. And as suspected setting color pallet to MWPF_TRUECOLORARGB fixed most of the problems. Now there is a funny thing that mouse cursor keeps drawing some blue squares on the background image where it should be transparent. It is something like npanel.c demo. But I guess that is caused by some modifications to the library.

[ghaerr]

Glad to hear most the problem is fixed by using previously required configuration.

there is a funny thing that mouse cursor keeps drawing some blue squares on the background image where it should be transparent. It is something like npanel.c demo.

Is that only on npanel, or does it happen when the mouse is moved over all/any windows?

But I guess that is caused by some modifications to the library.

This could be tested by using an unmodified desktop version of Nano-X. I would want to see the modifications to help debug, otherwise.

[AntumArk]

It happens almost every time mouse is dragged. There are although couple of image buttons which at least clear that cyan square but it is visible when moved.

Yes, I agree that I should test this on unmodified version. Though building demos is quite difficult as I am used to CMake and not Makefile 😅. I will try it out.

On Fri, 2 Dec 2022, 17:24 Gregory Haerr, @.***> wrote:

Glad to hear most the problem is fixed by using previously required configuration.

there is a funny thing that mouse cursor keeps drawing some blue squares on the background image where it should be transparent. It is something like npanel.c demo.

Is that only on npanel, or does it happen when the mouse is moved over all/any windows?

But I guess that is caused by some modifications to the library.

This could be tested by using an unmodified desktop version of Nano-X. I would want to see the modifications to help debug, otherwise.

— Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/69#issuecomment-1335415502, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ76CJL52TZ2VMGYTB326TWLIIDLANCNFSM6AAAAAASJCUMF4 . You are receiving this because you were mentioned.Message ID: @.***>

[AntumArk]

Haven't tried out unmodified on windows yet as makefile does not compile demos (tries but fails). Although modified version works fine on linux, no artifacts. Tested both screen types used (X11 and Allegro5). Continuing on trying to compile demos on windows.

[ghaerr]

Although modified version works fine on linux, no artifacts.

Are you saying that the version you're using works fine on Linux, but fails on your embedded hardware? If so, I would guess this may have something to do with the "alpha" bits (bits 24-31 in the 32-bit pixel). Can you find out what values it needs to be? By default, Nano-X will likely be using the value 255 for alpha.

[AntumArk]

Not on embedded. Windows 10. Yes, default values seem to be 255.

On Tue, 6 Dec 2022, 00:33 Gregory Haerr, @.***> wrote:

Although modified version works fine on linux, no artifacts.

Are you saying that the version you're using works fine on Linux, but fails on your embedded hardware? If so, I would guess this may have something to do with the "alpha" bits (bits 24-31 in the 32-bit pixel). Can you find out what values it needs to be? By default, Nano-X will likely be using the value 255 for alpha.

— Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/69#issuecomment-1338272009, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ76CMTA6VBEVLCEC2SN6DWLZUS3ANCNFSM6AAAAAASJCUMF4 . You are receiving this because you were mentioned.Message ID: @.***>

[AntumArk]

Alpha value problem fixed for images, there was new flag introduced which would skip old code.