RE: [AD] BUG: Page flipping and the screen

["Marcel Smit" <marcel.athlon@xxxxxxxxxx>]

> -----Oorspronkelijk bericht-----
> Van: alleg-developers-admin@xxxxxxxxxx
> [mailto:alleg-developers-admin@xxxxxxxxxx Eric
> Botcazou
> Verzonden: donderdag 20 februari 2003 11:45
> Aan: alleg-developers@xxxxxxxxxx
> Onderwerp: Re: [AD] BUG: Page flipping and the screen
>
>
> > I don't think this should be fixed on the GUI side. I think allegro
> > should maintain a bitmap which always points to the actually visible
> > portion of the video memory (the portion that is sent to the monitor).
>
> Maybe. But we would need to make sure that every single gfx driver comply
> with the semantics.

True.

> > Fixing this on the GUI side would be rather hackish.
>
> Not much more than the first solution I suspect.

I disagree. Not doing this on the GUI side makes a lot more sense. The GUI
cannot know where to draw to: the screen (possibly scrolled) or some
video bitmap.

Also writing our own dialog objects would be more difficult: where should
_we_ draw to?

> > In fullscreen mode, drawing to the front buffer immediatly shows on the
> > monitor. Draw a line, and you'll see a line. This is the way it
> should be.
> > With the block copying, the contents are not updated, until the
> next call
> > to show_video_bitmap (to do the block-copy again). Unfortunatly the
> > primary reason for drawing directly to the 'screen' is because we won't
> > have to bother calling this function.
>
> Do you have evidences of that? Anyway, I don't think we really support
> drawing onto the front page when page-flipping (but again, there
> is probably
> nothing in the docs that really prevents it).

Yes, I've tested this, and it really doesn't update.
It should be possible to draw to the front page.

I was wrong when I said the contents will be updated after the next call
to show_video_bitmap though. From wddwin.c:

<code>

	static int gfx_directx_show_video_bitmap_win(BITMAP *bmp) {

	  ..

	  /* guard against show_video_bitmap(screen); */
	  surf = DDRAW_SURFACE_OF(bmp);
        if (surf == offscreen_surface)
          return 0;

	  ..

        offscreen_surface = surf;

	  ..

	}

</code>

It says it gaurd against show_video_bitmap(screen), but what it
actually does is guarding against show_video_bitmap(front_page);

It's even worse: this prevents from the front buffer being updated.
I guess this makes sense in fullscreen modes. There is no need to
show the front page _again_, but in windowed modes it is block
copied.

> > Drawing directly to the screen is possible by drawing on the screen
> > bitmap, but this won't work in fullscreen mode, since screen isn't
> > updated.
>
> At least not with all gfx fullscreen drivers, yes.
>
> > If I understood everything correctly, it does in the 4.1.x series, but
> > from the following remarks I make up it will be discontinued:
> >
> > 	"The old way of page flipping (before the invention of
> > 	create_video_bitmap()) was to use scroll_screen() and keep track of
> > 	where to draw on the virtual screen.  So if the semantics of screen
> > 	changes, I think it might break old programs."
> >
> > 	"But now, after your remark, it seems pretty clear that the feature
> > 	would not be portable to the platforms with one flat
> surface of video
> > 	memory so it probably doesn't matter after all."
> >
> > (Still I think it should update the screen bitmap, because
> > show_video_bitmap and scroll_screen shouldn't be mixed.)
>
> But show_video_bitmap() is only a wrapper for scroll_screen() for the gfx
> drivers with a single flat surface of video memory.

I didn't know create_video_bitmap was supported there too. This kind of
complicates things even more. I think the only solution to all these
problems
(including the GUI, mouse) is what I suggested above. It will be a lot of
work to implement it, but I see no other solution.

>
> > To draw directly to the screen I now have to use two different
> methods: In
> > fullscreen mode, write to front page, and in windowed mode write to
> > 'screen'.
>
> Why does writing directly to the front page in windowed mode not
> work? The
> windowed gfx drivers ought to have the same semantics as the fullscreen
> ones: the changes in the frontbuffer are automatically copied to
> the monitor
> either after each group of drawing operations or periodically.

This is not true, because of the block-copying. I've tested this, and
it really doesn't work.