On complexifigurability (was: Re: [PATCH dix] dix: Added a "flat" acceleration profile that provides a linear pointer response.)

[Daniel Stone]

Hi,

On Tue, Apr 05, 2011 at 04:30:38PM +0300, Tiago Vignatti wrote:
> On 04/05/2011 04:05 PM, ext Daniel Stone wrote:
> >On Tue, Apr 05, 2011 at 03:45:58PM +0300, Tiago Vignatti wrote:
> >>and bonus points if we could disable/enable the acceleration
> >>architecture in compilation time also.
> >
> >If we get to that stage, something is _badly_ _badly_ _badly_ _badly_
> >wrong.  Rather than papering over the problem (assuming it is actually
> >large enough to notice at runtime, which I'm not entirely convinced it
> >is) and adding yet more alternate codepaths no-one will probably ever
> >test, we could just make accel acceptably small ...
> 
> maybe you are right.
> 
> But my point is (well, always was) to chop off the server internal
> modules in parts so we can have a lean implementation for different
> purposes and cover everyone's desires. The testing and conformance
> could be stressed in a different way, but not just compiling and
> forcing developers to use the thing.

Sure, but at some stage there has to be a limit.  Every configuration
option has a cost: in making the source files larger by putting #ifdefs
everywhere - and you could argue we already have enough of those, by
implementing the alternate codepath, by testing that both codepaths
build, by testing that both codepaths work, by documenting it, by
supporting users who use it, etc, etc.  The server is not exactly a
simple place as is, so adding additional complexity should be carefully
considered[0].

So, if there's a demonstratable benefit, then cool! By all means.  But
if we're doing it either just for the sake of it, or to provide an
absolutely trivial savings in binary size which could be much better
accomplished elsewhere[1], then I don't see that the tradeoff makes
sense.  Even so, is the result really usable? No-one using relative
devices wants no acceleration.

> Actually, by implementation of X11 we can pick all client libraries,
> headers, the server itself and drivers. So what motivated you to
> break them in pieces, when you started the autotools conversion?

Well, there was a huge and demonstratable benefit there.  We went from
releases being this insane nightmare that took months of work from
people dedicated almost exclusively to the task, builds being
next-to-impossible, etc, for very little benefit[2], users being -- and
rightfully so -- unwilling to test newer code until it hit
distributions, etc, etc, to where we are now.  The benefit vs. pain
equation comes out very very clearly on the correct side.  It wasn't
done simply for its own sake, it was done to solve existing and very
real problems that were causing us all huge amounts of pain.

That being said, I do think that modularisation went too far (why on
earth do we have 338 git repositories?!), and things like splitting the
app, proto and maybe font modules as aggressively as we did provided a
lot of pain for little-to-no discernible benefit.  That's exactly the
kind of thing I think was a poor idea in 2005, and I think is still a
poor idea in 2011.

So: what's the win here you're aiming for? Is it a reduction in binary
size? If so, can we gut enough of the acceleration infrastructure (such
that it's not actually an infrastructure) that the reduction is
basically line noise?

If not -- and we're just adding complexity for its own sake -- then I
just don't really see any merit.  Sorry.

Cheers,
Daniel

[0]: And in hindsight, I do wish I'd spoken out about the complexity the
     acceleration infrastructure introduced earlier.  My bad.
[1]: For instance, have you considered #ifdef'ing out the usage() text?
[2]: Having the drivers built with the server was quite nice, I'll grant
     you that.  But it also has its downsides, so ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110405/d2578b89/attachment.pgp>