Re: [AD] Fw: Acquire/Release speed issue

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> I'd say we should standardize on whats been told to many many many people
> for months and possibly years. :)

I think the DOS-like behaviour is really pointless: you can do the same with 
create_sub_bitmap(), which is the right way to do it.  And switching to the 
Windows-like one will not have any effect for those who use the trick you 
mention.

> Its not really silly. IIRC, the reason for that was DOS. a new video
> memory bitmap always allocated from the screen. And it could well be that
> way with the linux vga, svga and similar drivers... Now, the X and Windows
> drivers arn't like this, because they have very different semantics... the
> "Screen" is really just a handle to some form of drawable surface that may
> or may not actually being shown, or other things...

I think it is justified when you can allocate a video bitmap larger than the 
screen: in this case, it makes sense to include the screen in the bitmap.  
But this is not possible under Windows and other platforms that expose 
paged-like VRAM.

So we could standardize on the following behaviour:
- the first call to create_video_bitmap() with dimensions larger or equal to 
those of the screen, if successful, returns a bitmap including the screen.
- in every other case, the bitmap is allocated from off-screen VRAM.

> Ok. fine. As long as you fix all the drivers that are "wrong". :)

There is actually only one function to fix, in src/graphics.c, because the 
ports with a unique screen surface expose it directly to the generic code.

-- 
Eric Botcazou