Splendid - then I won't need to copy-paste some of the problems regarding right click menus locking the server and similar issues documented elsewhere - right? The X developers that have moved over to developing Wayland have explained these issues far better than I can.

Would you be kind enough to acknowledge these problems exist?

I get the feeling that people have invested so much energy and effort in X that they're reluctant to acknowledge the problems even exist. It's like some kind of programming Stockholm Syndrome.

A simple application capturing part of the desktop plus a live video feed with V4L and synchronised audio capture.

I started with just trying to capture the desktop + audio. Using either direct ALSA, pulseaudio or jack I would get scheduling issues and dropped X11 frames and/or audio underflow sometimes skipping multiple screen capture frames at once. Once I saw the problems programmatically I tried using the raw ffmpeg binary which exhibited the exact same issues either under a regular or realtime kernel. I did try with a recent compiled version, too.

We are getting way off topic with this discussion however. I feel my original premise (OSX is not behind X in terms of functionality or libraries) still stands.

> You know none of that stuff is in wayland either?

Yep, I was replying to GPs assertion that OSX has to catch up to X11.

> Also what's wrong with X event handling? You can select() on the events just like any others.

Have you ever written a real X protocol application or used one? Xedit, for example. The code is a mess of anachronisms (events targeted to sub-windows - if you are using them - modern toolkits don't now, excessively verbose error handling due to the historical cruft in the protocol etc) that haven't been brought into the 20th century due to the backwards compatibility needed.

Now you can say "yes, but these days everyone uses toolkit ##" - and you'd be correct, and you'd be using the toolkits abstraction on top of the X protocol and events. It gets messier when you want to add a sub-window with a GL or YUV surface. Now you're dealing with X, Toolkit ##, XGL and GL.

> Also, I've touched on OSX video handling. This is not a high point of OSX. Decoding a video and getting at the pixels is far, far better under ffmpeg than OSX.

Back when I moved onto OSX it took me about three days to get a custom screen + audio capture program up and running (with live preview) - something I was unable to getting working under X/ffmpeg and ALSA/pulseaudio without frame drops and synchronisation problems after many days of going grey. Feel free to blame it on my programming skill - but I found Apple's documented examples far easier to use as a base. Even using the ffmpeg binary alone with X11 capture and alsa/jack had frame drops and stalls in capture.

Perhaps this is a case of "better the library you know"? For me the OSX video handling is great and simple to use. Were you using the Objective-C bindings or talking C?

Friends, Country Men (and Women)!

This propaganda is exactly that which the Royalists would have you believe - without telling the complete story of waste and unsightliness they would foist upon us once again should we believe their lies!

Our royalist friend has failed to mention that under the Kings rule, some houses would remain half painted for a full day! It was due to the King having only limited time with which to grant delegation powers to the Minister of Composition who was powerless to get painting done without the Kings intervention.

Perhaps our royalist friend would also like to explain the excessive bureaucracy surrounding simple requests like even paint colors? Every simple request had to pass the Kings desk.

I for one would also like an explanation for the massive expense of maintaining a whole legion of Royally Approved color choosers that could only choose baroque antique color schemes that nobody wanted or commissioned.

No my Friends, the Royalists have but one agenda - to return us to the times of half painted houses and top heavy bureaucracy that punctuated our time as a Monarchy.

> Having seen terrible X compatibility layers for Mac OS X and Windows

The OSX X (XQuartz) implementation _is_ xorg-server (currently 1.14.4) - you know, the one used on Linux (with certain OSX specific tweaks to allow non-root mode)

The problems you mention with interoperability are largely down to the core windowing systems being vastly different models. We can argue about which model is correct but the interoperability problems are a side effect of different models - not evidence of a particular model being bad.

I'm not convinced from your descriptions here you quite understand the complexity of the interactions.

> The lack of X has been the main technical drawback Mac OS X has been
> having compared to Linux.
> I'd much rather see Mac OS X catch up with Linux than for Linux to go down
> to the level of Mac OS X.

OSX has vsync based updates, sensible event handling and lots of core library stuff (like the AVFramework) that makes it a pleasure to program compared to XWindows.

The Linux desktop _needs_ to get off X. It's an outdated behemoth with a model that is way out of date. Now you could say "well let's update the model then".

Sure, you can do that. And when you do that, you get Wayland.

If the Redhat guys have taught me anything it's that it belongs in systemd.

Pfft. I prototype in Java 7, then implement the real thing in C++.

I notice you haven't actually refuted any of my points, by the way. Go away, troll.

Yes, yes there is. Well, more than one actually. Here we go again:

(1) Unbounded stop the world of the JVM causing thread stalls (GC being the canonical example)
(2) Other stop the world's in the JVM due to code profiling causing a newly compiled version to be swapped in (maybe they've switched to atomics here, I'm not sure)
(3) Java's internal profiling and housekeeping absorbs CPU cycles
(4) Everything is allocated on the heap. If you have an array of objects - it's an array of pointers to things in the heap. There is no packed array of structs

These are the ones I've run up against when attempting to reduce scheduling latency in Java.

You can reduce the impact of (1), (2) and (3) using a realtime Java VM - but then you're not really writing Java - you can't use standard containers or standard libraries as they allocate memory all over the place. Also, the ahead of time compilation means you've lost the benefit of that lovely JIT re-profiling and optimisation.

(4) Can be mitigated a little by using NIO buffers with long offsets - but it's a mess and adds unnecessary extra computations to something that should just be pointer + offset.

To get down to it - with the standard Java VM I get scheduling latencies occasionally larger than 20ms - with C++ my thread scheduling latencies are measure in nanoseconds (i.e. less than a microsecond).

This is on a real time kernel with all appropriate thread priorities and such.

I'll be the first to admit to the myriad of problems with C++ (compilation speed and difficulty refactoring being my pet peeves) - but it has things that just make life more pleasant over C:

* RAII
* Standard library for algorithms, structures and so on
* Abstraction using templates are free - (well, one byte on the stack) and let you do (admittedly sometimes crazy) flexible things
* Abstraction at all
* Exceptions

You're welcome to your opinion, of course. I feel that C is overly simplistic and encourages re-implementation of the most mundane of things.

One look at things like GObject and GTK should at the very least make you question the sanity of accounting for every little thing. C doesn't leave you any choice - you must micromanage everything.

These people should be using a real time Java VM and an ahead of time compiler for those parts.

It means you can skip the warm up. The only problem with it is you can't hire regular Java guys - real time Java is a little bit special, and you can't use regular Java collections and other things in the ways you'd expect.

Look up DG Trade and Undertakings.

MS would be on very shady ground indeed in the EU if they tried it here.

Have you tried contacting the Xiph guys at all?

If email isn't working try IRC - they probably have a channel the devs hang out in, or their mailing list.

You have a nice suggestion and good grounds for it being a feature - do a little lobbying and see if you can get one of the devs to champion the feature for you!

I'm aware of such tests - but all they confirm is that pre-allocating a chunk of memory and re-using it is faster than individual allocate/deallocates.

That's not really that surprising. vector and other containers in C++ provide methods for storage (pre)allocation that can perform similarly.

If anything, it indicates that the program code is probably less than stellar C++ (stack allocations won't cost you anything and your destructors should be empty for value types).

Modern C++ shys away from OO derivations, too, where you should be using templates to get your abstraction for (almost) no runtime cost. Don't use virtual function calls - they're expensive - derive from a template class or use functors and get an inlined call for (almost - one byte) free.

Now don't forget Java has other things working against it (class recompilation, profiling, JVM stalls due to housekeeping etc).

A native compiled C++ program won't stall or halt your running threads. It's predictable.

Now we can argue about the effort to write decent Java and decent C++ and there I'll agree Java is a much more approachable language.

O dear,

Not this often repeated crap.

I'll give you that Java can be within an order of magnitude of C++ - but faster or as fast?

You're dreaming.

> It's terrible with multi-monitor, relative to windows anyway.

Yeah, was a deal breaker for me. I threw my toys out of the pram and installed Scientific Linux (Redhat Enterprise clone).

Now my workstation is gnome2 with realtime kernel 3.2, nice nvidia multi-monitor setup where I can get work done no fuss. It's occasionally a pain but I'm happy that I'm not burning through my SSD with updates every week.

I just found gnome3 too frustrating. I tried XFCE which wasn't bad but some little quirks annoyed me enough to fall back.

I'll stick with SL until we get to a nice place with Wayland and something stable and pleasant on top.