[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES sources for FreeMiNT 1.16.3
On Thu, Dec 10, 2009 at 4:10 AM, Jo Even Skarstein <joska@online.no> wrote:
> Vincent Rivière skreiv:
>
>> The VDI, as any other system library, could be seen as some kind of shared
>> library.
>
> Called via the trap-mechanism?
>
>> Each library interface could be materialized by a list of pointer to
>> functions. First a client program would have to get a pointer to that
>> interface, then to call the required function though its offset.
>
> But what about already existing applications? You would need to keep both
> interfaces.
>
>> That libraries could be designed to be run from user programs or from the
>> kernel.
>>
>> By the way, does the kernel have to call the VDI ?
>
> I see where you're going. No, the AES could be split into a server (for
> synchronising, event handling etc) and a client library (for drawing and
> interacting with objects and perhaps windows). I remember this discussion,
> and I like the concept. However, it didn't happen this way, and I don't
> think that we need to change the OS radically now that there's fewer
> developers than ever.
>
> GEM apps call the VDI and AES through a trap. They will always do this. So
> it makes sense to implement the AES like it is now, and implementing the VDI
> in the kernel is a natural progression. Then there will only be one AES/VDI
> trap handler, and the AES - which I would guess does the majority of VDI
> calls - don't have to call the VDI via the trap interface. And the VDI
> implementation might even be simpler, since one can reuse e.g. locking
> mechanisms that already exists in the kernel.
>
> Jo Even
>
and this allow for a good entry point for a new API, thru AES to VDI
(if km is not directly accessible from userland), and there is also no
reason why it cannot there for use pass-thru in its API, and this can
lead to a new way of calling VDI or calling a new VDI API
Anything that improves the speed, especially under MiNT.. because of
the tighter VDI AES (wheather KM or not) things like video rez and
color depth changes can be a real posibility, where they are not at
the moment
A union API could be the result, and something MyAES can benefit from also..
Paul
(Jo: appologies for loud emails/posts, no disrespect intended)