Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Paul Wratt <paul.wratt@gmail.com>]

On Fri, Dec 11, 2009 at 7:13 AM, Jo Even Skarstein <joska@online.no> wrote:
> Paul Wratt skreiv:
>
>> That is my point (i think). Any virtual screen should be independent
>> of physical hardware, and yes apps could be told about screen
>> attribute changes. As long as it is not a fullscreen non-desktop app,
>> then the virtual screen should not interfere with what is actually on
>> the screen, especially if it is running under AES
>
> This is a different concept than virtual workstations in VDI. In VDI, a
> virtual workstation is nothing but a set of stored parameters (colour, line
> style, fillpattern etc) attached to a handle we call a "virtual
> workstation". So when using a virtual workstation, you're only using those
> settings when drawing. The drawing is performed directly on the physical
> workstation (screen, printer, plotter...).
>
I think that the fundamental flaw in current VDI, the fact that
virtual workstation is not truely virtual (an abstraction iof the
physical screen), it just store certain information, and is a screen
reference to an app (from VDI's point of view).

> The concept you're suggesting can be compared to offscreen bitmaps in VDI.
> You could do all drawing to offscreen bitmaps in whatever size and
> resolution you like, and then blit it to the physical workstation when
> needed.
>
I would like to see something like this implemented for any AES app
that uses VDI from the desktop. If an app request a fullscreen rez,
then it can have a physical workstation instead, but that should not
mean that VDI can palm the output off in the same way, so essentially
a fullscreen TV reciever starts up, but asks the AES to show it in a
window, scaled, so VDI just remaps output for AES related rendering,
this might be a poor example, but the principle could be the same for
console apps, even to the point of per physical default fonts (if that
is applicable), allowing fullscreen using TTF or better font (for
example)

>> I am not sure of the use of multiple physical screens, except that
>> more than one full screen non-desktop app could be running at the same
>> time, and that would make sense, not interfering with each others
>
> This is one use. Movie players, slideshows, art programs, text consoles etc.
> are other uses. The Amiga had a brilliant implementation of this 25 years
> ago.
That and a few more hours spent thinking about what could be done with
and on future hardware, would have made for a "better" long term
impact, which is why now is a good time to "set thing straight". If
everything gets squared away nicely with multiple key speedups, the
old 8Mhz can be used in that current setup for many years to come (as
long as the powers supplies hold up). I dont expect "new OS" stuff to
be even small enough to fit on a floppy, and I dont think it is far on
the new hardware or modern development to still be held back in any
way.

But if all the basics are done properly, and and new API's AES, or VDI
still allow for the older hardware, it should not cause any conflicts,
but just make one piece of code workable on ANY Atari ST, and that has
always been a real problem, even when you could get official
documentation and followed the rules cleanly, there were still issues,
as there still are with older Amiga hardware, but they have a new OS
which overcomes those differences, to the point that the OS itself
will run on non-68k bases CPU's.

BeOS has just had the same thing happen, with the free community OS Haiku.

I would just like to see enough work put into getting base ST
usability up a couple of notches, before is it no longer possible, as
there will be ST setups coming together over the next few years that
will put even TT's to shane, and may even compete favorable with
Milans and CTxx's

>
>> On a hardware platform that support any form of graphics hardware,
>> multiple cards and multiple monitor are inevitable, an need to be
>> catered for from the start. If I ever get access to hardware that can
>> use PCI graphics, I have 2 64Mb Voodoo 5000, and it would be a crying
>> shame if I could not get direct access to there features. Note that
>> there are still PCI cards being made at the moment, which may not be
>> the case in years to come.
>
> With direct framebuffer access it's hard to take advantage of multiple
> monitors. It's much better to use the VDI to blit to/from the desktop (or
> whatever you would call it), as the VDI would take care of the issues with
> framebuffer address, pixel format etc. As long as the screens have the same
> colour depth (well, the VDI could easily transform the bitmaps while
> blitting, so this is strictly not necessary) and height, this would be
> completely transparent to all existing apps that use VDI only and no direct
> framebuffer access. These apps will just see one huge screen :-)
>
> Jo Even
>
There must be a way to get the best of both worlds, and alot of those
possibilities were covered in previous posts. There is a practical
solution to this and a flexible one too. I dont think a blocking mode
has been discussed yet, or a single TOS mode. A request by AES on
startup to allow or disallow "blocking mode" in combinations of (AES)
feature and process hibernation, would increase the performance of a
dedicated screen app, even to the point of changing kernel slices to
allow the three main processes to work faster (kernel, app, and VDI)..
until the app quits or the desktop is required for some reason..

Hmm, that sounds interesting..

Paul