Author |
Topic: Translating a line from a fast box blur algorithm (Read 1204 times) |
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
 |
Re: Translating a line from a fast box blur algori
« Reply #9 on: Oct 13th, 2011, 10:45am » |
|
on Oct 13th, 2011, 08:32am, Richard Russell wrote:| If you were expecting your version to be a lot faster than the GDI32 version, why? The code they use is probably quite similar, and it's running on the same CPU. The extra overheads and complications of the GDI32 version (principally things like having to support a range of different bit depths) aren't that great. |
|
My expectation for GFXLIB_DrawFilledCircle to be more than just twice as fast as the GDI32 circle plotter (which I think produces rubbish-looking circles at small radii - but that's a different story, although you'll probably take issue with it!), stems in part from the following observation (which I've shared with you before, possibly only privately though):
My game "Bugs" (a port of the Flash-based game "Ladybug Sumo"), featured my first attempt at an x86 Asm bitmap rotation routine (IIRC). And what a dire piece of code it is! The inner loop has 30 instructions per non-black (zero-valued) source bitmap pixel (including five IMUL instructions!); a code sequence that probably produces several CPU stalls per pixel, absolutely no attempt at pipelining / instruction pairing. It actually writes two pixels for each non-black pixel in the source bitmap as a frightful means of dealing with the problem of holes appearing in the rotated bitmap. In addition, no use of the stack to store local variables; they're globals read from (and in one case written to) main memory (although the reads are probably cached on most user's systems). So a pretty bad bit of code, all-round.
Yet it can draw a rotated bitmap at least as fast (if not faster) than the GDI's DrawIcon can simply draw a non-rotated bitmap.
I couldn't believe how slow DrawIcon was when I first had to use it in one of my early BB4W programs. It only had to render a few bytes of data! I remember thinking to myself, "Crikey! I've got a 733 MHz processor here, yet I've seen faster bitmap drawing on a BBC Micro". Which was probably a bit of an exaggeration, although that's how it seemed at the time.
DrawIcon was doubtlessly coded by highly paid, skilled software engineers who knew exactly what they were doing, and compiled their source code with a compiler that generated efficient code, yet I don't think I could write a bitmap plotter as slow as DrawIcon if I tried. I would literally have to put in a deliberate delay after each PutPixel()!
Of course, I realise that DrawIcon has to deal with a variety of colour depths - but so what? It would just need to call a different PutPixel subroutine depending on the colour depth, using perhaps a jump table or a short switch-case structure.
This is why I had expected GFXLIB_DrawFilledCircle to be significantly faster than the GDI's circle plotter (assumption being that the GDI filled circle drawer isn't using hardware acceleration).
EDIT: I admit that GFXLIB_DrawFilledCircle isn't exactly a shining example of efficient code either; for each horizontal line drawn, an external horizontal line drawer (GFXLIB_DrawHLine) is called, which in turn calls GFXLIB_ClipHLine. The circle edges are computed using x=((radius^2 - (y0-y)^2))^0.5, so one FPU fsqrt instruction per line drawn, plus a fild and a fistp. An integer SQRT routine would probably be faster, although precision might suffer.
David.
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Translating a line from a fast box blur algori
« Reply #10 on: Oct 13th, 2011, 4:21pm » |
|
on Oct 13th, 2011, 10:45am, David Williams wrote:| Of course, I realise that DrawIcon has to deal with a variety of colour depths - but so what? It would just need to call a different PutPixel subroutine depending on the colour depth |
|
Maybe, but that only deals with colour depth. There are other format variations such as the different ways of representing the 'mask' - encoded in each pixel as ARGB or as a separate monochrome bitmap - and encodings - e.g. PNG. One could in principle have an entirely separate DrawIcon routine for each different format, but perhaps Microsoft didn't think the overhead of that was justified.
DrawIcon also has to contend with issues such as clipping to the current Clip Region, and adapting to the current Mapping Mode. Again, it could have multiple routines - fast(er) ones that are called when there's no clipping or mapping, and slower ones when there is - but maybe it doesn't work that way.
Bear in mind that icons are not sprites! DrawIcon is not intended for displaying moving objects of the kind you might use in a game, it's intended for displaying a static icon in the corner of the window, or in the taskbar etc. So there's little incentive for Microsoft to put effort into making it efficient, when it's irrelevant for its main purpose.
When it comes to graphics primitives like circle drawing, it's probable that Microsoft will have put much more effort into optimising them, since they are indeed quite likely to be used in some speed-critical, dynamic display.
Richard.
|
| « Last Edit: Oct 13th, 2011, 5:27pm by admin » |
 Logged
|
|
|
|
|
