|
re: 4.2.1 seems to be fooked with font grabbing |
Neil Walker
Member #210
April 2000
|
Hello, Evert/anyone else, 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 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. Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
Elias
Member #358
May 2000
|
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. -- |
Neil Walker
Member #210
April 2000
|
Quote: This is with the SVN version of 4.2 and a memory bitmap. It is only slow with 32bpp system or video bitmaps, memory bitmaps are fine. Quote: And did you post some minimal test code 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. Quote: Maybe something specific is triggering the problem. 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... Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
Elias
Member #358
May 2000
|
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? -- |
Neil Walker
Member #210
April 2000
|
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. Quote: getpixel is known to be slow on video/system bitmaps, without locking. 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? Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
Evert
Member #794
November 2000
|
Quote: 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? Quote: 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? Quote: 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). Quote: 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. Quote: I thought you were only supposed to lock non-video bitmaps?
The oposite. You need to lock Quote: 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. |
Neil Walker
Member #210
April 2000
|
Quote: Forgive me for being pedantic, but did you make sure that it's actually using the patched version? Yes, I patched it myself and created new dll's and ensured they were being used by writing a log file at allegro startup. Quote: Do. And provide the sample font bitmap. I don't care if it's simple ok, font is already attached above. I'll knock out some simple code later. Quote: The oposite. You need to lock memory bitmaps 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. Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
Evert
Member #794
November 2000
|
See my edit above, I sometimes write faster than I think. Quote: 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? 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. Quote: My example of grab font from bitmap is video to video so locking shouldn't be used. The blit operation is, the alpha channel check uses getpixel(), which isn't. |
|