No, there is no law that prevents other people from seeing that you are broadcasting signals, much like there is no laws that make it illegal for a police officer to notice that you are smoking a joint.

Spectrum analyzers don't decrypt the signal, they only check for its presence.

No matter who loses, I run.

Hence why it also is likely to run afoul of some H.264 patents. It's a pretty unoriginal ripoff of H.264.

In software. Sloooooooooooooooowwwwwwwwwly.

Replying to undo accidental mod down :(

Maybe you completely failed to read the parent post... but the desktop OS and most applications would be native, not emulated. So you're only getting 50% to 75% in certain applications, but everything else runs native. Granted, Cortex A9's are slow, but certainly not terrible, and unfortunately have had a rather poor showing to most consumers in the incredibly inefficient Android. Because Windows 7 and 8 have hardware accelerated graphics APIs, any applications using them (including all the builtin ones) will probably feel just as snappy as my Core 2 Duo. Obviously, comptationally intensive apps will be slower, but most of those will probably appear recompiled quickly - ARM is especially easy because it can run it little endian mode, in comparision to x86 and PowerPC compatability.

Also, ARM recently announced their Cortex-A15 core, which will probably be making its way into SoC's pretty soon...

How about ARMv5TE and ARMv7-A?

On Mac, it's called CoreGraphics.
On Linux, it's called QPainter or Cairo.
On Windows, there are so many APIs that I don't feel like naming them all.

Android's graphics stack with the policy "let's do everything in software" is possibly one of the worst features of the platform. Most smartphones are capable of at least OpenGL ES 1.1, if not 2.0... and if you don't care about 2.0's features, there's only one API your compositor needs to implement to support ALL of the mobile GPU's out there. How's that for fragmentation? Of course, on dumb framebuffer phones, you'd probably want to implement a software fallback, as most software OpenGL ES implementations would probably be slower.

So Android needs two compositing backends then... how sad for them. Seriously, the fact that I need a 1.2ghz Cortex A9 to smoothly scroll though a list of icons is just pathetic. I mean, a NES can do that at 60fps... the magic of hardware acceleration.

Now draw a circle.
Now draw a bezier curve.
Now draw a circular gradient.
Now draw a button with the text "OK" on it.

If all you want to do is draw some textured quads, it's not terrible. However, textured quads can only get you so far, and what the original poster really wants is unknown.

The "wonky" compilation system isn't bad, and the benefits it provides overcome any ideological "oh my we are corrupting the pure and wonderful C++" feelings that I might have. It's really easy to integrate into CMake, and it doesn't matter with autotools, because everything is hard with autotools.

I also don't know where you got the idea that the VS plugin works only with paid versions. It works fine with the LGPL plugin for me.

While this can be a great thing, if you do this for the sake of separation, you'll do it wrong.
When separating your OS-dependent code, many people make a nice wrapper library for the various toolkits. This is a great way to reinvent the wheel yet again.
However, if you program is oriented around the GUI (a file manager, IRC client, etc), there is no good reason to separate GUI... you'll just end up with a poorly documented GUI abstraction layer. You'd be better off using any other portable GUI toolkit.

As much as the parent comment looks like an ad, I've used Qt and can say that my experience matches what the parent said.

I use Qt Creator as my IDE and it's great with the Designer integration. It's not quite as full-featured in some respects to Visual Studio or KDevelop (Qt works with VS as well), but the integration with the documentation and preprocessor makes up for it.

And the key is of course the documentation. Qt's documentation is possibly the best example of what a doxygen-based documentation can look like. Every class has a multi-paragraph and in-depth description, and most even have one or two code examples.

OpenGL? "Lightweight"? Sure, I suppose because it's all implemented in the system, you don't have to redistribute much, but have you actually ever written anything remotely complicated in raw OpenGL? For anything resembling a GUI, the poster is going to spend months of writing low-level code that's been done a thousand times already.

Qt is heavy, but it's heavy for a reason - it includes a very nice set of tried-and-true widgets, with all the nice features and weird corner cases thought of already. It's also fairly speedy, and even more so if you use QGraphicsView, which can be optionally accelerated via OpenGL for even more speed.

Qt also has nice support for custom widgets. You can subclass any widget, or QWidget, and make anything you want. You can even integrate your custom widgets with Qt Designer, either by promoting a placeholder widget, or writing a Designer plugin so your widget is WYSIWYG.

OpenGL is so low level that everything I talked in the last two paragraphs is completely beyond its scope. Even font rendering is rather arduous, and good luck with nicely word-wrapped, formatted text.

Excuse me, slashdot ate my comment, but to finish the second sentence:
IBM's Blue Gene is made up of a huge pile of fairly low clocked (less than 2ghz) dual core powerpc chips optimized for vectorized floating point operations.

Since when are GPU's not a valid CPU design? In fact, many of the top 500 resemble a GPU much more than your favorite old x86. IBM's Blue Gene is made up of a huge pile of fairly low clocked (
The part of GPU's that is general purpose is pretty much the same thing - a big pile of vector processors and a fat memory pipe.