From owner-freebsd-current@FreeBSD.ORG Thu Dec 2 07:50:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F34216A4CE for ; Thu, 2 Dec 2004 07:50:46 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA91B43D48 for ; Thu, 2 Dec 2004 07:50:45 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id iB27ob3H067330; Wed, 1 Dec 2004 23:50:38 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id iB27oao2067329; Wed, 1 Dec 2004 23:50:36 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Miguel Mendez In-Reply-To: <20041202075530.3b33db1b.flynn@energyhq.es.eu.org> References: <41AE3F80.1000506@freebsd.org> <41AE55D7.8020709@freebsd.org> <41AEA4B8.6080508@acm.org> <20041202075530.3b33db1b.flynn@energyhq.es.eu.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1101973835.66100.15.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 01 Dec 2004 23:50:36 -0800 cc: "Kamal R. Prasad" cc: current@freebsd.org Subject: Re: My project wish-list for the next 12 months X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2004 07:50:46 -0000 On Wed, 2004-12-01 at 22:55, Miguel Mendez wrote: > On Thu, 02 Dec 2004 10:44:32 +0530 > "Kamal R. Prasad" wrote: > > [Please don't top-post] > > > I find X windows to be a bit too compute intensive. Maybe something > > like apple's interface would be a good alternative [for those who > > don't need X-windows' powerful graphic features]. > > What makes you think so? X was originally desgined for systems with > little memory and processing power, certainly a lot less than today's > AMD and Intel space heaters. There are some features that do indeed > require more CPU, like antialiasing. That's the price to pay for eye > candy. Things like the composite and damage extensions do wonders to > help in those areas and make things like true transparency and alpha > blending possible. So, in time, X won't be that different from Aqua in > its use of hardware. > > The lack of speed in some apps can be blamed mostly on the toolkits. > GTK+ 1.2 was a speed demon, GTK+ 2.x is a lot slower. There are some > people working on a fast Pango code path that could make english text > rendering fast again. > > X gives you network transparency out of the box. I used an old SGI Indy > as an X term to connect to my FreeBSD box for years, and it worked like > a charm over a 10Mbit connection. > > Replacing X means writing something that's API compatible, or writing an > X server on top of your new display system, so that you don't have to > throw the thousands of X apps into the trashcan. Let me see if I can come up with a sensible response to this, which I've lost the original message for: We already have the stuff to do all of the pretty Apple eye-candy in X.Org 6.8, with the Composite/Damage/Fixes extensions. The same eye-candy support is a requirement to provide the perception of speed that you get out of other modern graphical systems, by removing the latency for redrawing when moving/mapping windows. You can use xcompmgr -a and compare what that gets you when dragging windows -- it's pretty decent. The problem we hit is when you try to add eye-candy, such as xcompmgr -c (drop shadows, fadey menus, etc.), things bog down. These are exactly the "powerful graphic features" that the combination of Composite and Render allow, and they're just like the operations Apple uses for all of their fancy stuff. The problem is that we aren't hardware-accelerating them currently. I've worked on building a moderately dumb X Server for ATI cards, and it gives apple-like performance on even Rage 128s -- it's not terribly complicated, just a matter of pushing things to hardware and avoiding the ~50x speed penalty of CPU reading from framebuffer. Now what we need to do is get a sensible acceleration architecture into X.Org so we can get these operations in hardware for all of the chipsets that we've got 3d docs or drivers for (ati, some nvidia, 3dfx, intel, mga, trident, sis, savage, gamma, and a bunch of others I'm forgetting). In short: There are no problems with X, except that we need somebody to bring us a sane acceleration architecture. I'm hoping I can get a job doing that this summer, as it'll be a significant undertaking that I can't get to while in my last year of school. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org Thank goodness for the 22nd Amendment