Tree reorganization (Was: Status of xserver/debrix/modular tree?)

[Bernardo Innocenti]

Daniel Stone wrote:
> On Mon, Feb 21, 2005 at 02:23:10AM +0100, Bernardo Innocenti wrote:

>>I'd really like to see render_bench in xapps/.  We may even define
>>the goal of the next Xorg release as "make Render perform as at least
>>as good as imlib with render_bench".
> 
> 'We'?  I'm sorry, but if you're not volunteering to do the work, then
> imposing random goals on others is a bit rich.

I was just making a proposal, not imposing anything on
anybody.  Don't you agree with it?  Then make a different
suggestion...

It doesn't actually matter what the goal is, as long as
it's clear that it's what the project is collectively
trying to achieve during the next iteration.



>>But they can only use the new technology for optional eye candy
>>like soft shadows and other window-manager related things.
>>
>>Most of the UI will still run on top of the legacy graphics
>>pipeline until Render/Glitz/Cairo gets mature and fast.
> 
> You do realise that one of the reasons running GTK apps under, say,
> XFree86 4.3, compared to under KDrive, shows such a massive speed
> difference is because it makes such extensive use of Render?

I thought Render was only being used for antialiased text
rendering through Xft.  Are rectangles with gradients drawn
with render?


>>The GTK guys are considering using Cairo to draw widgets.
>>QT has this new Andrew API that can use accelerated primitives
>>of modern APIs such as Quartz and GDI+, perhaps also Cairo.
> 
> ... yes, but what's your point?

That we'll soon have a crawling desktop unless we get Render
or GL acceleration for Cairo.  I've now read the XDC notes
by Adams and now I see it was already everybody's concern.


>>Yes, but since then things have not improved much, from the perspective
>>of a user.  Xserver still is a proof of concept that can't be used
>>on a desktop due to missing drivers and extensions.
> 
> So what?  Why should it be used on desktops?

Either that, or Debrix, or Xgl...  The current Xorg
server cannot support the accelerated primiteves required
by the new infrastructure, so it's a showstopper.

After the IRC session of yesterday, I understand that
people were discussing this topic already.  Not reading
about it in the mailing-list made me think that nobody
else was concerned.


>>I got it to compile with a few trivial changes, but the DRI/GL
>>enabled server hangs my machine shortly after opening an xterm
>>window.
> 
> Then don't use it.
> 
> As I said, it is a development platform.  Doing Composite work there
> enables people like toolkit developers to get the latest work as
> quickly as it can be done.  My point here is that toolkit developers
> have had since 2003 to play with Composite, and if they have held off
> doing so, then there's not much we can do about that.

I guess developers who have a dual-head ATI board won't be able
to do much with it.  Apparently, the Xati initialization looks for
the wrong PCI function and fails.  I've hacked make_busid() until
I got it to work, but now it hangs as I said.

To debug that, I should probably run it under gdb from a remote
shell.

If Xserver is going to be the only server where desktop and toolkit
developers can test new technology, they need something easier
to build and run.  Maybe Xnest-like servers could be used instead,
but they're a bit slow.


>>I've read many many posts asking to keep old stuff in Xorg,
>>even if it increases the maintenance burden of all developers.
>>What I've learned from GCC is that patches that remove old
>>code are more valuable in the long term than patches that
>>bring in new stuff.
> 
> You're preaching to the choir, but this doesn't really apply to drivers.
> 
> At the end of the day, our mission is to produce a usable X server.  If
> we ship with ati, nv and i810, we have utterly, utterly, utterly failed
> in that mission.

I understand.  We've already discussed the chaos that resulted
when XFree86 4.0 had to be installed alongside with XFree86 3.3,
but maybe we could explore it another time.

With the modular tree, installing two different X servers
wouldn't be as inconvenient.  Maybe a simple solution to
this dilemma is providing a new KAA or Xgl server for
modern hardware *and* the old XAA server for old boards.

These two servers may probably share a good percentage
of auxiliary code (configuration parser, module loader,
etc.).

Would such a solution be appealing?


>>As you said, X carries an incredible amount of legacy
>>code and should be made lighter to ease maintenance,
>>provide smaller footprint implementations for embedded
>>devices, etc.
> 
> ... are you volunteering?

No.

> Do you know how much work is involved here?

I can only guess.




>>At this time, we already have two competing projects.
>>I don't know whether it would be easier/better to
>>import Xorg stuff into Xserver or vice-versa, but
>>one of these things must be done.
> 
> 'Must'.

As I said on IRC, when I say 'must' I don't intend
to force my will on anyone.  If in English "must"
sounds like a command, perhaps I should have said
"should be done" or "needs to be done".  Such semantic
difference is difficult to catch for me.


> Look, I'm sorry, but the point I've been making for the last couple
> of weeks or whatever now is that X simply does not have enough
> contributors.  I'm glad that you have invaluable and extensive
> experience in GCC, but coming in here and telling everyone they have to
> start rewriting XAA on top of KAA or something when you are not fully
> technically informed of the issues is not going to help, or endear
> yourself to anyone.  What we need is more contributors pumping out solid
> code, not more people pumping out hot air on lists saying 'well what you
> really need to do is throw away the DIX because no-one needs that and
> rewrite it for some reason'.  There is enough uninformed punditry about
> what X needs to do and what it needs to be in Slashdot comments already.
> 
> Sorry if this is overly harsh, but just rambling on mailing lists means
> nothing at this point.  Contributing solid code does.

My whole point was that coordination and planning are a
requisite for writing useful code and ultimately deliver
working software.

I think so because in the past I've seen commercial projects
slipping schedule forever despite having a team of talented
developers, just because of bad project management.

This also happened in our company just a couple of years
ago, and the bad project managers were us.  Instead of
defining goals and assigning tasks, we desperately tried
to help by writing random code, thus causing even more
damage.

Coordinating large software projects is an incredibly
difficult task.  Technical skills alone arn't sufficient.
I think we've improved over the last years, but we still
need to learn quite a lot.

As for OSS vs commercial software, I believe there's
no difference at all.  A good development process works
fine in both worlds.  In fact, our development process
improved by borrowing practices commonly found in OSS
projects: mailing-lists, public code reviews, tracking
bugs with Bugzilla, automated regression tests, frequent
releases, documenting with Doxygen, sharing portable code
across different projects...

I know I have very little technical knowledge of the Xorg
code base, that's why I make so many questions (and thank
you for taking the time to reply).  If you re-read my
postings, you'll notice that my statements on technical
issues are either direct questions or attempts to summarize
previous discussions.

I'll try to improve my knowledge of X because I find it
an intriguing piece of software, but it will take some
time.  Meanwhile, excuse me if I get some things wrong.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/