Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Slow blitting in windowed mode?

This thread is locked; no one can reply to it. rss feed Print
Slow blitting in windowed mode?
axilmar
Member #1,204
April 2001

Hi, I've got the following code:

1int main() {
2 allegro_init();
3 install_keyboard();
4 install_timer();
5 install_mouse();
6
7 set_color_depth(32);
8 set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0);
9
10 BITMAP *page1 = create_video_bitmap(SCREEN_W, SCREEN_H);
11 BITMAP *page2 = create_video_bitmap(SCREEN_W, SCREEN_H);
12 clear_bitmap(page2);
13
14 int x = 0;
15 while (!keypressed()) {
16 circlefill(page2, x, SCREEN_H / 2, 64, makecol(255, 255, 255));
17 acquire_screen();
18 for(int j = 0; j < SCREEN_H / 32; ++j) {
19 for(int i = 0; i < SCREEN_W / 32; ++i) {
20 blit(page2, screen, i * 32, j * 32, i * 32, j * 32, 32, 32);
21 }
22 }
23 release_screen();
24 ++x;
25 }
26
27 readkey();
28 return 0;
29}

Blitting is very slow...the same code in full screen mode is so fast that I can't see the circle moving, while in windowed mode it moves very slowly.

Does anybody know something about this?

Marcello
Member #1,860
January 2002
avatar

All I can imagine is it's hardware accelerating video-video in fullscreen, and not in windowed?

Maybe add some acquire/release bitmaps calls?

Marcello

Evert
Member #794
November 2000
avatar

Never acquire video bitmaps if you're doing vram->vram blits. You should only acquire bitmaps if you're going to do non-accelerated operations on them.

Just about the only circumstance in which you should use acquire_screen()is if you're doing a memory->vram dirty rectange system.

EDIT: in other words, drop the acquire()/release() calls.

Paladin
Member #6,645
December 2005
avatar

Are you trying to use page flipping? If so, where do you flip the pages at? Why don't you look at Shawn Hargreave's examples since he has something very similiar to this in the double buffer and page flipping examples.

axilmar
Member #1,204
April 2001

Even if I drop the acquire/release, the problem remains.

I am not trying to use page flipping, but buffering from vram.

I think maybe the problem is due to pixel conversion...because If I reduce the color depth to 16, then the speed is more than doubled.

Evert
Member #794
November 2000
avatar

What's your desktop colour depth?
In windowed mode, the actual colour depth is the desktop colour depth. If you set anything else using set_color_depth, you will get colour conversions, which are slow.

Felipe Maia
Member #6,190
September 2005
avatar

Is there a way to get the desktop color depth?

Evert
Member #794
November 2000
avatar

Yes.
Try your friend the manual.

Richard Phipps
Member #1,632
November 2001
avatar

If you put the circlefill itself outside the inner loop, does that give you a significant speed up?

axilmar
Member #1,204
April 2001

Quote:

What's your desktop colour depth?

32 bpp, as it is in the code.

Quote:

If you put the circlefill itself outside the inner loop, does that give you a significant speed up?

The circlefill is already outside of the inner loop.

Richard Phipps
Member #1,632
November 2001
avatar

while (!keypressed()) {
        circlefill(page2, x, SCREEN_H / 2, 64, makecol(255, 255, 255));
        acquire_screen();
        for(int j = 0; j < SCREEN_H / 32; ++j) {
            for(int i = 0; i < SCREEN_W / 32; ++i) {
                blit(page2, screen, i * 32, j * 32, i * 32, j * 32, 32, 32);
            }
        }
        release_screen();
        ++x;
    }

You are drawing the circle every frame, and drawing directly to video memory is known to be pretty slow.

If you could just blit the circle (but time the frame rate) you would have a better idea of how slow the blitting is..

axilmar
Member #1,204
April 2001

Quote:

You are drawing the circle every frame, and drawing directly to video memory is known to be pretty slow.

I don't think so. Only translucent drawing is slow on vram.

Quote:

If you could just blit the circle (but time the frame rate) you would have a better idea of how slow the blitting is..

The same code in full screen runs so fast you can not see the circle moving; all you see is a big white stripe.

Maybe there is conversion of pixels between RGB (which vram uses) and BGR format (which Windows uses); allegro devs could confirm this.

Richard Phipps
Member #1,632
November 2001
avatar

Quote:

I don't think so. Only translucent drawing is slow on vram.

If your hardware is accelerating some primitives like GFX_HW_LINE then you might get fast drawing. Otherwise it could be the cause of the slowness.

All I'm saying is it could be worth testing to see if it is this than spending a lot of time on the blitting and gfx mode side.

axilmar
Member #1,204
April 2001

Quote:

If your hardware is accelerating some primitives like GFX_HW_LINE then you might get fast drawing. Otherwise it could be the cause of the slowness.

All I'm saying is it could be worth testing to see if it is this than spending a lot of time on the blitting and gfx mode side.

No, I've already said that: if you do the test in full screen mode then it is so fast you don't see the circle moving, just a big white stripe. So it is definitely not the drawing.

If you also remove the for loop and do the blitting with one call, speed is good. The trouble is with tiled blitting.

Evert
Member #794
November 2000
avatar

Quote:

Maybe there is conversion of pixels between RGB (which vram uses) and BGR format (which Windows uses); allegro devs could confirm this.

If they knew about Windows programming and the innerworkings of the DirectX driver... maybe.
Anyway, Allegro should use the native RGB ordering used by the video mode (which is why you load bitmaps aftercalling set_gfx_mode()).

Richard Phipps
Member #1,632
November 2001
avatar

Axilmar:

Ah, I misunderstood. My apologies!

If things are that slow it sounds like the display is being converted or emulated in software somehow. Do AllegroGL programs also run slowly for you in a window?

Go to: