>> Anyway I think that this simpler solution would benefit the whole
>> system
>> performance and even make the app_server simpler to write and
>> maintain.
>I'm not so sure about that. Having a direct connection between an app
>server and an application entity seems to be a very straight forward
>model. At least not more complex than to multiplex/demultiplex the
>communication.
The main advantage lies in the reduced usage of 'critical' system resources
(threads, semaphores, ports) and reduced need of synchronization of a
possibly big number of threads.
>> While we are at it, i just read the other posts regarding rendering
>> and I
>> have a few ideas to discuss with you:
>> app side rendering is a nice idea as it would reduce the load on the
>> app_server, which in turn would 'just' have to coordinate shared
>> resources.
>> Clearly hardware acceleration must be available on the app side.
>I don't think, it's a good idea to move too much functionality of the
>app server into the applications. A clear client/server approach will
>e.g. make it easier to transparently implement the feature of running
It wouldn't be different, I mean the code which does rendering in the
app_server right now would be 'moved' to the app side, but would provide
equivalent functionality.
>> A second step would involve rendering windows off screen: this
>> solution would
>> allow nicer screen updates (ala Dano) and would make later support of
>> OpenGL
>> for screen compositing almost immediate. Clearly we need to allocate
>> gfx ram
>> space for these window bitmaps to take advantage of all hardware
>> features.
>I believe, that has already been mentioned and IIRC DW said that it
>should be rather easy to implement.
That's nice, it would solve several possible future problems.
--
Massimiliano Origgi
http://www.intuiware.com mailto:max@xxxxxxxxxxxxx
Squeezer 2.2 NOW available!
WorkspaceSwitcher 2.2 available!