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