al_init();
al_init_primitives_addon();
al_init_image_addon();
etc----------
I called all the necessary functions to make a window from the main function. Then I used al_clear_to_color(al_map_rgb(200, 100, 150)); and it works fine - no problem.

I called all the necessary functions to make a window from the main function. Then I used another thread to call al_clear_to_color(al_map_rgb(200, 100, 150)); but it shows error(not working). It's acting like as if the thread that called all the necessary functions like al_init() and etc..... are in control. Can anyone help me fix it?

Hai Elias, thanks for answering
I never thought this forum is this much active - I admire and respect peoples like you (really) Thanks...

I fixed it in a weird way.
Every thread that goes to the rendering subroutine will go through this ->
// Note:- AClass contains the display variable

However it is working, but sometimes it is throwing an exception. Is it a good way to get this done?
Also, I heard that the thread with the control to the display's back buffer must load the bitmaps or else they will be loaded in RAM rather than into the graphics RAM(resulting in lag). Is it correct?
One more thing- can you explain why 3.44 KB PNG file, when loaded using al_load_bitmap(), takes ~3MB of memory space?

Test :
Normal execution : 27 MB

Load bitmap (an image) 88*2064 pixels
Execution : 35 MB

Create bitmap (blank) 88*2064 pixels
Execution : 33 MB

Thanks, Chris Kato
I did some research on the memory issue and found some information like the total m/y space for an image x *y pixel (long and wide) would be x*y*3 for RGB. I calculated a rough of 0.5 MB for a pic which takes up 5 MB of space in reality. Is it normal or I am leaking m/y or stuff? I double checked for memory leak but didn't find any.

You guys are amazing...
I wish I had some friends who are pro programmers.

That'd probably be because you forgot to multiply that by the number of bits per channel

total pixels = width * height
bits per pixel = 32 = 8 bits * 4 channels (red, green, blue, alpha)

minimum bits needed to store image = total pixels * bits per pixel

Taking this into account, the minimum size for your 88x2064 image as stored in memory would be:

88 * 2064 * 32 = 5812224 bits

This equates to about 750kB, which is a fair bit less than the 3MB you mentioned. However, there will be other things taking up space; we haven't yet accounted for all of the bitmap's metadata, struct padding, or any other memory that Allegro or libpng may have had to allocate to facilitate the loading of images.

Your paint program should have an option to save as a 24 bit png. Or you can just use .bmp.

A note : The same image, encoded as .bmp or as .png, may be smaller as a png due to its compression. .bmp is not a compressed format.

If you want good compression, export as a .jpg with various levels of quality. Quality level 70 still looks very much the same as the original, but gets really good compression.

You're welcome. I always like giving players another life. xD

What? WHY?

Also, you can always convert bmp to PNG using any other program afterwards. If you're on Linux, it's super easy, with plenty of terminal one-liners.

Would you rather take less disk space, or load faster? The only format you should use for images is a compressed texture, as I said earlier.