Date: Tue, 10 Mar 1998 07:52:34 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: "Kaleb S. KEITHLEY" <k.keithley@opengroup.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: WINE (was: Uncle Sam, got a million bucks?) Message-ID: <Pine.LNX.3.96.980310073632.11844B-100000@phobos.illtel.denver.co.us> In-Reply-To: <350403F3.7AC7@opengroup.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Mar 1998, Kaleb S. KEITHLEY wrote: > Christopher Sedore wrote: > > > > I'd like to see an lightweight X11 replacement (eg photon), > > Where is there information on photon? > > Lightweight in terms of what? Bandwidth? Memory footprint of the > application? Something else? > > > What strategy does photon offer for preserving the investment that > various enterprises have made in their existing X11 applications? Or are > you going to pull a Java on me and tell me that the apps have to be > rewritten? IMHO the best way to keep X and make something more efficient than Motif over it will be to make a toolkit that can be used either on a client side (like existing toolkits) or as an extension on the server side, and programs will be able to use either of those ways. Server-side implementation decreases the bandwidth, improves human-perceptible response time and frees some memory at the client at the expense of memory at the server that I believe, will be acceptable -- the additional memory spent on the server will be probably significantly less than one currently spent on clients, and definitely something can be done to improve locality of the memory access on one server while it can't be done on multiple clients or even on objects, dynamically allocated in one client (start Netscape, press right button, hear familiar sound before menu appears). When X is used over the network, in most of cases it's more reasonable to decrease the memory use on the client application even if X server will take more memory to handle it, and I think, it still will be increased less than what will be saved on the client -- a lot of low-level objects that now are handled by toolkits will exist only in server. Client-side or protocol-proxy implementations will provide fallback for existing servers that don't have or can't use server extension. -- Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980310073632.11844B-100000>