Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

Posted Mar 25, 2003 9:00 UTC (Tue) by libra (guest, #2515) [Link]

I would mostly agree with that argument.

I always feel sad when I have to use vnc (which for me is a heavy solution) when I want to administer remotely a Linux PC, just because I do this administration from a Windows computer and having a X on windows is too much complicated (heavy) in my opinion.
So the point for me is that X client/server model is in fact very good and make sense. The point should be to make it more user friendly now when it comes to remote connection.

Posted Mar 28, 2003 5:17 UTC (Fri) by Peter (guest, #1127) [Link]

As I understand this "issue" (well, IMO it's a non-issue) the conflict is about either persisting with the client-server model, which _some_ people consider to be too complex for _single_ desktop systems, or breaking X's built-in network independence by going for a streamlined model.

One should also note that this "issue" is only being heard from the peanut gallery. I haven't heard one word about this from any actual X developers, or for that matter from anyone who seems willing to "put up". Oh, except for those comments from Havoc and others, to the effect of "not gonna happen" or "have you even profiled it?"

Posted Mar 28, 2003 10:21 UTC (Fri) by Duncan (guest, #6647) [Link]

> The very idea of XFree86 forking is probably
> enough to cause waves of jollity at Redmond.

I'm of that opinion as well, unfortunately.

> As I understand this "issue"[,] the conflict is about either persisting with the
> client-server model, which _some_ people consider to be too complex for
> _single_ desktop systems, or breaking X's built-in network independence by
> going for a streamlined model. My personal view on this is that the X standard
> was way ahead of its time; to me it seems wholly perverse that there should
> even be discussion about breaking the client-server model at this time.

I agreed with you originally, but then read something that at least caused me to
seriously consider the alternative viewpoint. From my reading, the reality isn't
quite as simple as you make out, or rather, most, including you, it would seem, fail
to realize just how much that complexity point you raise, means.

The issue has to do with XFree's Render.. as laid out against OpenGL, or
perhaps a new, later generation alternative (that point remains to be debated).
Both OpenGL and Render, according to the explanation I read, do essentially the
same thing -- they are both vector drawing APIs -- only while OpenGL is designed
for both 2 and 3D, Render only handle 2D. Since they both do about the same
thing (in 2D space anyway), there's a large degree of needless duplication of
functionality, though of course the implementation differs.

Thus, the initial question becomes one of "Well, going forward, doesn't it make
sense to emphasize OpenGL and eventually depreciate Render?" However,
that's only the initial question, because it in turn brings up a host of others.

Level two then becomes "If X is going to simply rely on calling its own OpenGL
implementation to do the drawing anyway, and we have 3D apps in particular
calling OpenGL on top of X, then X going back and calling its own OpenGL to do
the actual rendering, doesn't it make more sense to expose the OpenGL
implementation directly, eliminating a level of redundancy and (at least in theory)
increasing performance dramatically?"

Which then of course brings us back to the original debate, as we would then be
implementing and exposing OpenGL directly, with current client/server model X
being layered on top of it.

IOW, it all comes down to a question of why have two levels of redundant
functionality doing essentially the same thing, with all the extra code and
performance inefficiency that implies? Why not implement the more advanced
one, OpenGL, directly, then expose both it, and the current client/server X model,
including its current Render functionality, as a layer on top of the direct OpenGL
implementation.

That's the basis of the proposal. There are a few loose ends to wrap up,
however. One is simply politics. Doing it this way will (and obviously does) look
to some like deserting the original client/server model, when that isn't being
proposed at all, only a re-ordering of the functionality stack to eliminate
functionality duplicated at two levels, with subsequent exposure of the 3D aspects
of OpenGL directly at the lower level where it would replace 2D only X-Render.

Second, there's the repeated "Well, have you profiled it?" "Can you show us the
actually improved performance?" Of course, these are legitimate questions. The
problem is that the level of worked required to do this is non-trivial to say the
least, and it's still very early in the process -- we are still debating it. It's a major
rewrite, substituting one API for another as it does, and eliminating an entire level
of duplicated functionality. OF COURSE it hasn't been profiled yet -- the task is
going to take some serious time to complete. The question is do we start now,
keeping XF86 unified as it heads towards that goal, fork it, with all the undesirable
consequences, with one branch maintaining the current course, and the other
undertaking the rewrite, or put it off another several years, until the job is even
MORE difficult, X even MORE encrusted with hokey and slow work-arounds, and
even LESS satisfactory a solution as a modern 2D
AND 3D visual rendering environment.

Now, I don't want to pick sides, here. Obviously both forking and putting it off are
less than desirable solutions, but it appears one or the other will happen, due to
the politics of the situation. I've explained the techical side. I've read some pretty
serious allegations on the political side about possibly selling out XFree to a
proprietary solution. I haven't the foggiest if they are true, but even if they were
THOUGHT to be true, I can see how that might be grounds for kicking someone
off the team. OTOH, XFree isn't as open as many other open source projects in
the first place, it would seem, according to several sources I've read, which might
be part of the problem.

Finally, the legitimate question has been raised, "OK, if we are looking at a major
re-architecturing and rewriting anyway, isn't this a good time to examine whether
OpenGL is actually the best solution either, or whether a new solution might be
better?" Remember, a number of the OpenGL patents originating with SGI are
now in MS's hands, and serious questions have been raised as to the continuing
viability of the protocol's openness, or even existence, given MS' history in the
area of open standards, and the fact that altho it has *NOT* announced any legal
pressure on OpenGL per se, it HAS resigned from the commitee spearheading it,
and says it intends to focus exclusively on DirectX, on MS platforms. While it's
possible any potential intellectual property concerns could eventually be coded
around anyway, if necessary, if we are already considering doing a major re-write
of XFree, now the major player in the X consortium, now would be a VERY good
time to re-examine whether OpenGL is the absolute best possible solution in light
of those IP concerns in the first place.

[Meta: Wow! Long comment, but I believe it does address the issues as I
haven't seen them addressed in any response to this story so far. I can't say I'm
fully convinced of the rightness of the entire viewpoint I've presented here, but I
*DO* believe the issues ought to be examined from all sides, and it seemed only
one side had been presented, so far, and that not in any real depth.]