Re: My project wish-list for the next 12 months

On Wed, 2004-12-01 at 22:55, Miguel Mendez wrote:
> On Thu, 02 Dec 2004 10:44:32 +0530
> "Kamal R. Prasad" <kamalp_at_acm.org> 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_at_lclark.edu          
http://people.freebsd.org/~anholt/         anholt_at_FreeBSD.org
           Thank goodness for the 22nd Amendment