Re: [AD] 4.3 graphic drivers

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2005-11-11 at 22:38 +1100, Peter Wang wrote:
> How about this (partly DirectX-inspired) proposal?  Start with the first
> version of the vtable.
> 
>     typedef struct VTABLE_V1 {
> 	void (*some_method)(int blah);
>     };
> 
>     void register_vtable_v1(VTABLE_V1 *vtbl);
> 
> Drivers would statically fill in VTABLE_V1 instances, as they do now,
> with type checking.
> 
> Now say we want to add a new method to the vtable, and change the
> function signature of an existing method:
> 
>     typedef struct VTABLE_V2 {
> 	void (*new_method)(blah);
> 	void (*some_method)(float blah);
>     };
> 
>     void register_vtable_v2(VTABLE_V2 *vtbl);
> 
> register_vtable_v1() would need to adapt V1 vtables to V2:
> 
>     void register_vtable_v1(VTABLE_V1 *v1)
>     {
> 	VTABLE_V2 *v2 = allocate_v2_vtable();
> 	v2->v1_vtable = v1;
> 	v2->new_method = NULL;
> 	v2->some_method = v1_some_method_adaptor;
>     }
> 
> I'm not sure where v1_some_method_adaptor is going to get the address of
> v1->some_method from.  Presumably the same place as all the other
> suggestions so far.  Once we decide V1 compatibility is no longer
> needed, it can be thrown out.

Maybe each VTABLE needs a pointer to all the predecessors?

Also, we should decide (with all suggestions) when
adaptors/compatibility vtables are thrown out and registering the driver
simply fails instead.

One way (in order so we don't actually get DX complexity) would be
before every release. So the example of just adding a new test-entry
would not break other drivers/platforms and could be committed to CVS -
but before each 4.3.x release, someone should go through all drivers and
update them to the new version, allowing to throw out the old one.

Of course, this would not solve the problem of addon drivers - but
instead of crashing, the register function would fail and set the error
string to something like "This driver is written for an earlier version
of Allegro. Please ask the maintainer to update it.".

> > As for strings versus ID's... I don't have a strong preference either way 
> > apart from a feeling that strings are somehow overkill.
> 
> At least with enums you get spell checking.

You still get it with strings, but at runtime :) Anyway, I don't have a
real preference. With the strings, I was mostly thinking about that old
config system proposal.. so we could re-use the general string
handling/hashing parts.

-- 
Elias Pschernig