On Tue, Feb 22, 2011 at 5:11 PM, Fons Adriaensen <fons@email-addr-hidden> wrote:
> On Tue, Feb 22, 2011 at 04:38:05PM -0500, Paul Davis wrote:
>
>> what its going to do,i think, is two-fold:
>>
>> 1) promote more and more toolkit design that makes everything just a
>> compositing stack. GTK has already moved significantly in this
>> direction, but could go a lot further.
>> ....
>
> Makes perfect sense. And indeed X is old, large parts of it
> have become more or less useless, and there is certainly room
> for something new. If and when that arises and gets 50% of the
> maturity of X then I'll be happy to use it.
this model is actually already about as old as X. from my perspective
Display PostScript is a precursor to all these new ideas, in some deep
sense. as for the technology involved, most of wayland is evolving
alongside X, rather than separately, since they share GPU drivers etc.
etc., and toolkits like Qt and GTK simply come with different
backends. you could run more or less any GTK app on a wayland display
right now, and most of the issues will be identical to issues with the
app on other display platforms. there really isn't going to be a
"catchup" period - more of a co-evolution accompanied (probably) by a
slow drift of more and more basic platform technologies to a
wayland-style model. an awful lot of the "maturity" in X relates to
the network model and things like ICCCM, rather than the drawing &
event models, which were finalized in very closed to finished form a
long long time ago and didn't really require much maturation. wayland
drops the network model, and right now i forget quite how it handles
the sorts of issues that ICCCM addresses.
> 2. But at the same time this is sort of backwards. There is no reason
> today why a computer display should be driven by a 'video' signal that
> refreshes the complete screen at a fixed rate. *That* itself is very
> old technology and completely useless in this age.
very true. on the other hand, think of it as an equivalent of a
non-periodic, but still completely synchronous version of JACK. the
timing can come from applications own needs rather than the h/w, but
having a "central dispatcher" avoids some of the ugliness that people
dealing with video and animation have faced with X from the beginning.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Feb 23 04:15:02 2011
This archive was generated by hypermail 2.1.8 : Wed Feb 23 2011 - 04:15:03 EET