|
rectfill or putpixel |
Onewing
Member #6,152
August 2005
|
Is: rectfill(spr, x, y, x2, y2, makecol(255, 255, 255)); the same as: in terms of time? However, the main question that I want answered is this: if I have a group of pixels that work together, should I rectfill with a mask or just put each pixel? For example, ******* ***-*** **---** *--------- --***** ******* Say the above -'s were my pixels that needed to be manipulated. Would it be faster to put each pixel at each -, or rectfill (from the lowest x and y to the greatest x and y pixel that is actually being used) and than put another masked rectangle over it, with holes cut in it for the -'s to be seen? Does that make sense? ------------ |
Archon
Member #4,195
January 2004
|
Quote: in terms of time? No way. At least, not for DirectX (I don't know how xlib works). You're going to have to send more header data (each putpixel vs 1 rectfill) - a single putpixel would be faster than a single rectfill, but not when you multiply it's usage. That's why drawing larger bitmaps is faster than drawing many more smaller ones. Quote: However, the main question that I want answered is this: if I have a group of pixels that work together, should I rectfill with a mask or just put each pixel? For example, rectfill with mask I'd reckon - it's closer to the hardware layer. |
miran
Member #2,407
June 2002
|
Quote: Is rectfill putpixel in terms of time? Definately not. Make a small test that draws a million rects and the same with putpixel and measure time. The second will be much slower. As for the main question, make a small test that draws a million of your typical shapes with rects and the same with putpixel and measure time to see which one is faster. I think you won't be surprised to find the method with rects to be significantly faster. If it was the other way around, I would be surprised... -- |
CosmicR
Member #6,889
February 2006
|
short answer: rectfill is faster than putpixel.
|
Onewing
Member #6,152
August 2005
|
Quote: make a small test that draws a million of your typical shapes with rects and the same with putpixel and measure time to see which one is faster Can do and will! Thanks all! ------------ |
gillius
Member #119
April 2000
|
If you are trying to draw a complex shape like that and fill it, probably the best way to do it is to use hline. hline is more likely to be hardware accelerated than other drawing methods, and if software drawing is needed, hline should be very efficient. I don't know if rectfill is implemented with hlines or if it is its own separate function capable of hw acceleration, so I could still be wrong. Gillius |
A J
Member #3,025
December 2002
|
rectfill is x2,y2 inclusive, your loop is x2 y2 exclusive. ___________________________ |
Tobias Dammers
Member #2,604
August 2002
|
Nothing a simple subtraction couldn't fix. --- |
A J
Member #3,025
December 2002
|
calling makecol() for each pixel vs calling makecol once. obviously rectfill is quicker. calling putpixel() for each pixel vs calling rectfill once. calling a function incurs an overhead. ___________________________ |
Onewing
Member #6,152
August 2005
|
Quote: calling makecol() for each pixel vs calling makecol once. obviously rectfill is quicker. In my program, I actually have the int returned from makecol saved in a variable called WHITE and I use this instead of makecol. Quote: calling putpixel() for each pixel vs calling rectfill once. Yes, but I wasn't sure if rectfill was using putpixel itself to fill out the rectangle. ------------ |
HoHo
Member #4,534
April 2004
|
Quote: In my program, I actually have the int returned from makecol saved in a variable called WHITE and I use this instead of makecol. Doesn't matter much. A function call itself takes huge amounts of cycles compared to initializing a pixel value. Quote: Yes, but I wasn't sure if rectfill was using putpixel itself to fill out the rectangle. Probably it writes several pixels at once. Also, putpixel checks for bitmap bounds. so for 1000 putpixels there are 1000 bounds checks but for one rectfill there is only one, a tiny bit more complicated bounds check. __________ |
Thomas Harte
Member #33
April 2000
|
Quote: Probably it writes several pixels at once. The default software implementation breaks the rectangle into horizontal spans and does the equivalent of calling hline (but goes straight to the internal vtables to save a redirection). The DirectX definitely has an accelerated version, I'm not sure about the other drivers. It also has an accelerated hline. Assuming you are drawing to a video bitmap, there is therefore a gigantic world of difference in Windows - putpixel isn't accelerated in any way but instead does a lock/store/unlock cycle. With a putpixel loop you can't avoid a framebuffer lock, with rectfill you'll usually avoid one. Conversely if your bitmap is already locked then you're in a much more complicated position. It's almost certainly still smarter to go with rectfill though for function overhead and clipping reasons. EDIT: I do of course use lock/unlock like everything else on the planet, so read as acquire/release for Allegro purposes. [My site] [Tetrominoes] |
Onewing
Member #6,152
August 2005
|
I think I'm having a brain-fart. How would I go about flood-filling a set of pixels that wasn't in the shape of a rectangle (other than using a putpixel loop)? [EDIT] ------------ |
gillius
Member #119
April 2000
|
Unfortuantely there is no "do_floodfill" function in Allegro, as far as I can see. Gillius |
psycho
Member #5,042
September 2004
|
You could "speed up" the putpixels: You just have to take care that you have to take another code for other color depths as 32 bit, and that it just works with memory bitmaps. But it's a lot faster and with this method you can blit a bitmap nearly as fast as with blit(). |
gillius
Member #119
April 2000
|
That would never beat out a hardware accelerated method, though. Gillius |
A J
Member #3,025
December 2002
|
memory bitmap blits are rarely hardware accelerated. ___________________________ |
Onewing
Member #6,152
August 2005
|
I actually found my putpixel method better than floodfill, both in speed and presentation. ------------ |
gillius
Member #119
April 2000
|
AJ, I was referring to the original suggestion I made about hline. Memory blits from Allegro's own structures are never hardware accelerated, but vram->vram blits are extremely fast if your one and only goal is to "blit bitmaps." Gillius |
|