Re: Some perspective from the cheap seats...

On Sun, Mar 23, 2003 at 07:36:07AM +0000, Keith Whitwell wrote:
>David Dawes wrote:
>> On Fri, Mar 21, 2003 at 04:38:21PM -0500, Mark Vojkovich wrote:
>> 
>>>On Fri, 21 Mar 2003, Egbert Eich wrote:
>>>
>>>
>>>>Havoc Pennington writes:
>>>> > IMHO, one thing X.org should do if it wants to reimagine itself is
>>>> > expand to include toolkit/desktop level concerns and establish
>>>> > contacts with toolkit and desktop developers. X should really be
>>>> > developed to meet the needs of the UI, not the other way around.  That
>>>> > goes from the top down: user -> apps -> desktop -> toolkit -> X -> OS.
>>>> > 
>>>>
>>>>Havoc, 
>>>>
>>>>I do agree with you. However you most not neglect issues t
>>>>hat are not immediately visible from the UI point of
>>>>view: you have to consider how you can map a funtionality
>>>>you propose onto the HW. 
>>>>
>>>>In the past this has not always been taken into consideration.
>>>>I hope Mark Vojkovitch will give more details on this but
>>>>to give you two examples:
>>>>
>>>>* Alpha blended cursors have been added with no consideration 
>>>>  for OpenGL.
>>>>
>>>>* The RENDER extension is nearly impossible to accelerate fully.
>>>>
>>>>Egbert.
>>>
>>>  The cursor issue was fixed a the last minute, so were some
>>>other problems, but some problems still remain.  In fact, part
>>>of 4.3's delay was due to regressions caused by the RandR 
>>>extension not getting fixed in a timely matter.
>>>
>>> The fact of the matter is that few people realize the implementation
>>>issues involved in some of these features.  End users say
>>>they want a particular feature, but specify things in a way that
>>>is nearly impossible to implement or implement efficiently.
>>>
>>>  Things like RandR really require radical driver model modifications
>>>to implement in a non-hackish way.  Implications to OpenGL or Xvideo
>>>still aren't entirely clear.  This can't happen overnight as everything
>>>needs to fit together coherently and this is alot of work, and work
>>>that can't really be done by people who don't have experience in
>>>these areas.  In some cases features were added without sufficient
>>>considerations.  Desktop people pretty much got to pick their dream
>>>interfaces with RENDER but this leaves driver people scratching their
>>>heads as to what they're expected to do about it.  Concerns about
>>>the useability of the current design were expressed by people like
>>>Thomas Roell from XiG and myself.  I suppose someday people will
>>>be complaining that RENDER is too slow and blame the XFree86 project
>>>for this, though it was really the consequence of end users having
>>>too much control.
>> 
>> 
>> That one has been puzzling me for a while.  I recall when the RENDER
>> extension was first being discussed that one of the motivations
>> for it was to expose hardware functionality.  At the time, Carsten's
>> Enlightement was doing similar things, but handled entirely on the
>> client side.  Yes, there are other benefits from having a RENDER
>> extension, but its seems that the purpose of exposing more hardware
>> functionality got lost somewhere along the line.
>> 
>> I think this does show a fundamental difference between the guys
>> on the desktop side and the traditional XFree86 developers.  The
>> former seem like CS types, only really interested in software
>> solutions, while the latter tend to be more engineering types who
>> care a lot about getting as much out of the hardware as possible.
>> I definitely fall into this second category.
>> 
>> Anyway, I recall in Thomas Roell's discussion about RENDER that he
>> did find significant performance benefits to accelerating it, once
>> he figured out a reasonable way to do it (and he is no slouch so
>> the fact that it took him several attempts to do it speaks volumes).
>> Thomas and XFree86 are pretty much competitors in some market
>> segments, and I find it a little disturbing that a competitor is
>> getting significantly better performance out of an extension that
>> originated here.  Actually, I find it a little embarrasing when
>> someone asks me about a solution that requires the best possible
>> render performance and I have to say "well, ours isn't accelerated,
>> so you'll have to go to XiG".
>> 
>> It's easy to say "fast enough" is "good enough", but "fast enough"
>> can depend a lot on the eye of the beholder.
>
>There were a bunch of GL types trying to influence things in the early days, 
>with specifically the sort of concerns that now seem to be causing you 
>problems.  It didn't seem like much notice was being taken of us -- would an 
>elder GL type on advisory board have had more sway?

I don't know why the input from the GL types (and others) was
ignored.  Those who actually did the work on RENDER (primarily
Keith Packard) ultimately made the decisions on how to proceed.
In the model we have where those doing the work determine the
direction, that's as it should be.  Some of those who implement
will be more open to advice than others.  I think that competition
is a good thing, and it was disappointing that the GL types didn't
feel strongly enough about it to demonstrate a GL-based alternative.
It could have been a big win for GL, and could have done a lot to
move the desktop in general in that direction.

David
-- 
David Dawes
Release Engineer/President                      The XFree86 Project
www.XFree86.org/~dawes