Hello,
Apologies for the rather long delay in http://www.allegro.cc/forums/thread/589885

Evert/anyone else,
I've recompiled and tested the patch supplied in the above thread and it makes no difference at all sadly.

Just to recap: run grab_font_from_bitmap on a 32bpp video bitmap and you get a rather long delay.

6 bitmap files of average size 350x150 pixels and 32bpp

as memory bitmaps: sub second
as video bitmaps but at 16bpp: 2 seconds in total
as system bitmap: 50 seconds per bitmap, 5 minutes in total
as video bitmaps: 3 minutes per bitmap, 18 minutes in total

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.

But to put it in context I can start off the program to process 6 small bitmaps, put on my trainers, run a round trip of two miles, have a quick shower, grab a beer from the fridge and sit down before it finishes, despite the cpu being able to process 2.5 billion instructions a second and the graphics card being able to draw 25 million triangles a second.

I just tried grabbing a 961 x 409 bitmap, and it finishes in an instant. So I tried grabbing it 100 times, and it takes a few seconds only. This is with the SVN version of 4.2 and a memory bitmap.

I'm too lazy to look at the code, but oprofile says this:

27767    35.3783  _linear_getpixel32
11718    14.9301  getpixel
11398    14.5223  font_find_character
9569     12.1920  bmp_read_line
8599     10.9561  bmp_unwrite_line

and the callgraph for getpixel:

  9         0.0142  _bitmap_has_alpha
  15        0.0237  grab_font_from_bitmap
  415       0.6569  bitmap_font_ismono
  1242      1.9661  import_bitmap_font_color
  1685      2.6673  bitmap_font_count
  59806    94.6717  font_find_character
11718    14.9301  getpixel
  45754    72.4426  _linear_getpixel32
  11718    18.5532  getpixel [self]
  2911      4.6090  bmp_unwrite_line
  2776      4.3953  bmp_read_line

So the blame seems to be in font_find_character.. but anyway, it seems to be really fast here. Can you try the SVN version? (Else I'll try it here with an older version and see if it gets slower.) And did you post some minimal test code and the bitmap you are using? Maybe something specific is triggering the problem.

It is only slow with 32bpp system or video bitmaps, memory bitmaps are fine.

FONT* MainFont=grab_font_from_bitmap(FontMainBmp);

Is that small enough

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 - the attached font is only 8bpp but is converted to 32bpp when you read it into the created video bitmap.

I don't know what else to say really, the fault is at grab_font_from_bitmap on a 32bpp bitmap. The fault seems to be the new bit of code to handle alpha-channels. I can try and work out how to profile it if you want, but I've never compiled against the profiler before...

Oh, had not seen that it's fine with memory bitmaps. Hm, I'd say, getpixel is known to be slow on video/system bitmaps, without locking. So maybe a single call to _bitmap_has_alpha is enough for the slowdown. Do you notice a difference if you put acquire_bitmap/release_bitmap around grab_font_from_bitmap?

I thought you were only supposed to lock non-video bitmaps?

How do you use the profiling information? I compiled with -pg, got my gmon.out file and ran 'gprof game.exe > log.txt'. It generated shed loads of stuff but there wasn't a single entry for 'grab_font_from_bitmap', the function it was called from - setupgame() - was there but I couldn't find anything useful.

I know, but 18 minutes is rather taking the piss isn't it? 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?

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.

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?

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.

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.

The oposite. You need to lock memory video bitmaps if you're doing non accelerated operations on them.

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.

Yes, I patched it myself and created new dll's and ensured they were being used by writing a log file at allegro startup.

ok, font is already attached above. I'll knock out some simple code later.

Reading the manual there seems to be two cases when you don't use acquire_bitmap: 1) video to video operations, 2) when your target bitmap for writing is a memory bitmap regardless of anything else. Anything else you should? My example of grab font from bitmap is video to video so locking shouldn't be used.

See my edit above, I sometimes write faster than I think.

You don't use acquire_bitmap on accelerated video operations. That includes accelerated video->video blits. acquire_bitmap() doesn't do anything on memory bitmaps.

The blit operation is, the alpha channel check uses getpixel(), which isn't.