rectfill or putpixel
Onewing

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?

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

short answer: rectfill is faster than putpixel.

Onewing
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

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.

A J

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

Tobias Dammers

Nothing a simple subtraction couldn't fix.

A J

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

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.

gillius

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

psycho

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

That would never beat out a hardware accelerated method, though.

A J

memory bitmap blits are rarely hardware accelerated.

Onewing

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

gillius

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

Thread #575708. Printed from Allegro.cc