Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:How well does XWayland work? (Score 1) 340

Yes. I've hacked aroud(sic) in xlib a lot.

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.

I started recording live TV on a Linux box in 2003. I never had problems. What were you trying to make?

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.

Comment Re:How well does XWayland work? (Score 2) 340

> 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?

Comment Re:In a country far away and long ago.... (Score 2) 340

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.

Comment Re:How well does XWayland work? (Score 4, Insightful) 340

> 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.

Comment Re:C++ can operate at the very limits (Score 2) 371

There is no reason Java can not run just as fast and predictably as C/C++, given people who know what they are doing.

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.

Comment Re:performance is not black and white (Score 1) 371

Being a big "C" booster these days, most of my hate is reserved for C++. It is a language with no home. Overly complicated, not as lightweight as C, and not as easy to use as Java or .NET. I could speak at length about its problems.

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.

Comment Re:Warm up is a big deal (Score 1) 371

The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.

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.

Comment Re:Essential Features.. alpha support, lossless. (Score 1) 86

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!

Comment Re:Java at least as fast as C++ (Score 1) 405

However, modifying the C++ version to utilize custom new and delete operators for the necessary classes to cater to the specific demands of such an application once again pushes the C++ version's performance ahead of Java, as expected.

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.

Comment Re:So, they heard the complaints... (Score 1) 267

> 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.

Comment Re:LOL Java (Score 1) 233

> Did you perchance use JVisualVM to look at what your program was doing? what was it doing when spending time? sometimes the hotspot will become obvious

Yeah with various tools (jprofiler, visualVM, sysprof, strace, latencytop etc).

The problem with running Java profiling tools is that you have to leave UsePerfData on - and it's a cause of jitter in the VM itself.

The code is as optimised as you can get - I'm bypassing the "helper" classes included with JavaJack and using the raw mapping to Jack C API.

When running the program is at about 2% of CPU - so it's not a CPU starvation problem. I've run it under both regular and realtime linux - the linux thread priority is set by Jack itself as high - and I've tried setting the other threads in the VM to lower priority by native C calls. No dice.

> What was the delay? It should have been sub-millisecond. It is definitely not the source of the 40 ms delay that you see.

The problem I think is that it's competing with the compilation / profiling and housekeeping threads for CPU, and the VM can halt your thread whenever it feels like the profiling data or other things need updating.

I should mention that I'm outputting two periods of 1024 samples - so Java is in effect failing to meet a 20 millisecond deadline every now and then.

> I'm not sure whether you are aware of this, but to get low jitter you must yield.

I'm not very happy with this being a solution - if anything it shows the model is broken itself.
I can't even try this - the callback thread is created inside the Jack shared library - and "enters" the VM when it needs to do a callback. I can't block or do anything other than simply try and return the data needed by Jack in this thread.

It's been an entertaining discussion - but I think we're at an impasse - I think I've demonstrated some scenarios in which Java either lacks expressive tools or fails to offer the same guarantees that native C++ can offer.

Please don't forget - I am a Java developer - I'm not poo-pooing the language with bias - but realising the limitations of the tools we use is important in being able to identify the situations in which the tools are appropriate.

Cheers

Slashdot Top Deals

Vitamin C deficiency is apauling.

Working...