Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » rectfill or putpixel

Credits go to Archon, CosmicR, and miran for helping out!
This thread is locked; no one can reply to it. rss feed Print
rectfill or putpixel
Onewing
Member #6,152
August 2005
avatar

Is:

rectfill(spr, x, y, x2, y2, makecol(255, 255, 255));

the same as:

for(j = x; j <= x2; j++)
   for(k = y; k <= y2; k++)
       putpixel(spr, j, k, makecol(255,255,255));

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?

------------
Solo-Games.org | My Tech Blog: The Digital Helm

Archon
Member #4,195
January 2004
avatar

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...

--
sig used to be here

CosmicR
Member #6,889
February 2006
avatar

short answer: rectfill is faster than putpixel.

Onewing
Member #6,152
August 2005
avatar

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!

------------
Solo-Games.org | My Tech Blog: The Digital Helm

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
Gillius's Programming -- https://gillius.org/

A J
Member #3,025
December 2002
avatar

rectfill is x2,y2 inclusive, your loop is x2 y2 exclusive.

___________________________
The more you talk, the more AJ is right. - ML

Tobias Dammers
Member #2,604
August 2002
avatar

Nothing a simple subtraction couldn't fix.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

A J
Member #3,025
December 2002
avatar

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.

___________________________
The more you talk, the more AJ is right. - ML

Onewing
Member #6,152
August 2005
avatar

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.

------------
Solo-Games.org | My Tech Blog: The Digital Helm

HoHo
Member #4,534
April 2004
avatar

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.

__________
In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
MMORPG's...Many Men Online Role Playing Girls - Radagar
"Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

Thomas Harte
Member #33
April 2000
avatar

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.

Onewing
Member #6,152
August 2005
avatar

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]
Yep, twas a brain-fart. My question had the answer in it, asuming that works better than a putpixel loop.

------------
Solo-Games.org | My Tech Blog: The Digital Helm

gillius
Member #119
April 2000

Unfortuantely there is no "do_floodfill" function in Allegro, as far as I can see.

Gillius
Gillius's Programming -- https://gillius.org/

psycho
Member #5,042
September 2004

You could "speed up" the putpixels:
Do it like in the documentation of Allegro described:
((long*)scrnbuffer->line[y])[x] = color;

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
Gillius's Programming -- https://gillius.org/

A J
Member #3,025
December 2002
avatar

memory bitmap blits are rarely hardware accelerated.

___________________________
The more you talk, the more AJ is right. - ML

Onewing
Member #6,152
August 2005
avatar

I actually found my putpixel method better than floodfill, both in speed and presentation.

------------
Solo-Games.org | My Tech Blog: The Digital Helm

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
Gillius's Programming -- https://gillius.org/

Go to: