I've recompiled and tested the patch supplied in the above thread and it makes no difference at all sadly.
Forgive me for being pedantic, but did you make sure that it's actually using the patched version?
I don't remember if I commited the patch yet, but it should be anyway (since the check for the alpha channel should really only be done once).
Also, do note: the new version that checks for alpha channels is always going to be slower than the version that didn't care about them anyway. However, it doesn't need to be as slow as stock 4.2.1.
I know grabbing from video bitmaps is a bit daft, but it's fine with 16bpp, only 32bpp is bad, which it wasn't before the change to check for aliased or transparent fonts.
That's because the code has to check every pixel in the bitmap to determine wether there's an alpha channel or not in 32bpp mode. Again, are you absolutely sure that it's only checking for the alpha channel once?
I can post a sample, but really it's simply you start a standard allegro program with 32bpp depth, create a video bitmap and populate it with a bitmap font
Do. And provide the sample font bitmap. I don't care if it's simple, I'm not going to bother writing the test program to test this with as well as do the test, especially if you already have the test program and especially if I have to do it in Windows (doesn't make sense to do the check in X11 anyway).
I may have a little time this evening or on saturday to boot into Windows and try it, though I don't think I have anything installed at the moment.
the graphics card being able to draw 25 million triangles a second.
Yeah, but can it read from the same surface area at that rate (and no, it can't). Actually, drawing with an alpha channel enabled shouldn't be done with Allegro's video bitmaps anyway, since that requires a read operation.
I thought you were only supposed to lock non-video bitmaps?
The oposite. You need to lock
memory video bitmaps if you're doing non accelerated operations on them.
I say dump the alpha channel check (or whatever it is that was added to the grab funciton) and/or add it as an optional parameter to do the transparency check, or even add a 'grab_font_from_bitmap_ex()' function?
No. It just adds more complexity to the API and more functions that need to go into the compatibility layer, just to play nice with something that you should not be doing in the first place.