Re: [AD] stretch_blit GFX_HW_VRAM_BLIT ?

[Elias Pschernig <elias@xxxxxxxxxx>]

> > From what I understand, the 
> > new stretch_blit would work for VRAM and SYS_TO_VRAM, so 4 new flags
> > instead of 2 new flags would be needed..
> 
> Yes. This actually raises another problem: the gfx_capabilities flags are 
> almost all taken. What do we do with new capabilities that we might add? 
> Create a more_gfx_capabilities variable? Use a function-call to decide 
> which one to populate (much more work and error-prone because internally 
> we'd still need gfx_capabilities and more_gfx_capabilities-like variables 
> and current functions directly set gfx_capabilities).
> Or do we just call it done and don't add new hardware accelerated features?
> The latter would be the easiest way, but then, we really shouldn't be 
> adding this to 4.2 either!
> I personally think more_gfx_capabilities is the least of all evils. 
> Hmm... alternatively... what happens if we increase the width of 
> gfx_capabilities to 64 bit? Would older programmes (taht think it's 32 
> bit) using the newer dynamic library just see the lower 32 bits?
> 

I think, in 4.2, another variable would be ok, if we really need it.

For 4.3, I think we should use a function call. Internally, the
information could maybe get stored in the vtable - if we go for the
vtable version which adds a version number for each entry, then we can
as well add some bits to each vtable entry telling what it can
accelerate. A global variable won't work for sure, since there may be
multiple AL_DISPLAYs, each with different capabilities.

-- 
Elias Pschernig