Luiz Americo Pereira Camara wrote:
In a recent thread i discussed with Marc the alpha bitmap design, and was pointed that would be no performance penalty if a 24bit bitmap is used in a 32bit color display since the number of bytes per pixel would be equal. Initially i agreed but i found that this info is incorrect.

While adding the DIBsection to TBitmap I realized that I was wrong. Till then I thought it was possible to specify a bpp=24 while the actually space used was 32bits.

A 24bit bitmap uses 4bytes/pixel (in average) in some sizes (1,2,3 pixels) to fill the dword boundary. When the dword boundary is filled with 3bytes/pixel (4 pixels), it will use 3 bytes/pixel, in other situations (5 pixels) the bytes/pixel is not constant. So a bitmap with 1,2,3 pixels will have the same size using 24bit or 32bit (4,8,12 bytes), a 4 pixels bitmap will use 12 bytes and 16 bytes respectively, a 5 pixels bitmap will have 16 and 20 bytes.

I also tested the performance of such issue. A program that bitblt 1000 times a 200x200 bitmap in a 32bit color display give the results below (an 77% overhead over 32bit bitmap). Attached is a program (used fpc 214, XP SP2, celeron D 1.4 512MB). In the other side 24bit bitmaps use less memory.

Although i disagree with the design/solution (using a 24bit bitmap by default in 32bit color display), that has performance issues and other side effects, the bitmap support improved with recent changes and i wont question this issue anymore, as the current LCL code.

Please stop thinking for win32 only. Sure both win32 and gtk has issues with this (win32 is completely braindead regarding alpha drawing, while gtk is lobtomized). I don't have them for carbon or QT. I try to find a common solution and I'm indeed not happy with the performance drop in the current situation, but despite that, it works! We have at least some alpha support, while bitmaps arent mutilated by some mask.

The info here is just for clarify a misconception.

Anyway, thanks for the bench tool.

Marc



_________________________________________________________________
    To unsubscribe: mail [EMAIL PROTECTED] with
               "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to