Paul Wratt skreiv:
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
I'm afraid I don't understand.
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
You mean switching resolution on the fly, like in most other operating systems? If so, this is not a limitation of the API, but a limitation in the design of AES and VDI. Current applications will simply not be able to recognise a resolution switch without a restart. However, it's not a bad idea. There are mechanisms in AES today to tell applications about a resolution change, but it has never been tested because no AES is capable of doing this (well, MagiC can, sort of). Applications that doesn't flag their knowledge about this can simply be shut down. So I think it's something that's worth looking into.
A union API could be the result, and something MyAES can benefit from also..
The API will not change. Both AES and VDI use the same trap today. The trap handler will be common (and thus more efficient), but the API will be the same.
Jo Even