Re: [MiNT] XaAES / GEM memory issues

[Henk Robbers <h.robbers@chello.nl>]

Sven Karlsson wrote:
> 
> Hi again,
> 
> "Konrad M. Kokoszkiewicz" wrote:

> > Gui related (or anything related) device driver: yes. This is perfectly
> > okay, as long as this "driver" does not draw windows or manages clipping
> > rectangles (because clipping is somthing that _is_ dependent on certain
> > gui, isn't it?).
> 
> Ehh? no!
> 
> All efficient window systems I know of sends redraw messages to the
> connected clients/applications whatever that force them to redraw only a
> piece of the screen, i.e., the visible part of one of their windows.
> 

These rectangles are derived from the window and client lists.
Window list and client list together form a database.
This database has 2 record types and 1 set as follows:

clients  -----> windows
         1 to n

The part of XaAES that handles it is the part that runs in user mode.
Needless to say that this database is inaccessible to other processes.
Running as a seperate process that has the database in private memory ensures
its integrity.

The resulting rectangles have to be passes to the users parameterblock in reply
to a wind_get AES call. 

Whatever design, somewhere we needd passing information between processes.
Moving data from one memory space to another can only be done by the kernel.

This involves communication protocols.
People are already complaining about the speed of these protocols.

A complete user context based AES is not possible.

-- 
Groeten; Regards.
Henk Robbers.    mailto:h.robbers@chello.nl
                   http://members.ams.chello.nl/h.robbers/Home.html
A free multitasking GEM for MiNT: XaAES (heavily under construction);
Interactive disassembler: TT-Digger;  Experimental text editor: AHCX;