Flash is jerky full screen

[joncrndl]

When content is displayed inside the browser, the action on screen is smooth. It gets choppy, when put to full screen mode. The same content is smooth when using Linux Mint 9 64.
The screen on this Lenovo T61 is 1680x1050 with the Nvidia graphics controller. My copy of Linux Mint includes the non-free Nvidia driver.

[Kevin McAleavey]

Feb 20, 2011 21:03:31 GMT -5 joncrndl said:

When content is displayed inside the browser, the action on screen is smooth. It gets choppy, when put to full screen mode. The same content is smooth when using Linux Mint 9 64.
The screen on this Lenovo T61 is 1680x1050 with the Nvidia graphics controller. My copy of Linux Mint includes the non-free Nvidia driver.

Hey there! Well ... sounds like it's time for an attack of the story monster about our flash thingy so it all makes some sense. There are a number of variables at play here, most of them completely beyond our control at this time, and others that we've mitigated as best we could for now. KNOS runs on a BSD kernel and there is not, nor was there ever a version of Adobe anything for BSD. Just getting them to support Linux (poorly) is something non-Windows/OSX people are supposed to be grateful for. IBM tried to get them to release a Linux version of Flash for Redhat and that never happened. It wasn't until Ubuntu ponied up a *lot* of money that they released a semi-functional set of proprietary libraries which are optimized for Ubuntu but not so well for other "linuces."

Because BSD never supported anything Adobe, it became incumbent on us to support Adobe Flash, PDF and Sun Java as part of an expected browser implementation for our business users as well as home users. The only way this could be accomplished then was to extend the existing BSD "Linux Compatibility Layer" which dates back to Redhat 4! In fact, making all of this possible was what took both us and numerous BSD teams over two years to accomplish, greatly delaying the KNOS Project itself. And thanks to all involved, our Linux Emulation Layer ("sandbox" or "virtual machine" to the non-technical) is compatible with Fedora Core 10 in our current incarnation which is sufficient to run Adobe's Linux Flash plugin within KNOS. Between the Linux stuff and some other QT-based stuff, KNOS is more than three times larger in size than it would be were we to not support Flash, Java and multimedia. But we felt it absolutely necessary to do so in order for KNOS to be as complete as any other commercially-accepted full operating system and environment.

So first, we had to pretend to be Linux as far as Adobe's stuff is concerned, but there were other issues before we could make Adobe work in KNOS. Flash is heavily infested with DRM ("Digital Rights Management") routines in order to make the studios happy to let people watch their content. This requires TCP ("Trusted Computer Platform") or what I like to call the "big tattler" plus all sorts of encryption and protection of the streaming media that appears in Flash. But for us (and BSD) this all presents a very serious security risk because Flash wants to bury itself deeply into the operating system and hide many of its hooks. Because of Flash's design, this is the reason why there are so many exploits and security holes in even permitting Flash to run on any computer. And so our Linux Emulator, which talks directly to our kernel, was seen as woefully insufficient for us from a security standpoint. By our security standards, if Flash could go anywhere within our system, then so could anybody else. NO WAY!

And so, between Flash and the emulation layer, there is yet another sandbox and another fake Linux within a wrapper called "npviewer.bin" ... this sandbox replicates the Linux emulation layer and works to convince Flash that it really *is* deep within our system when it actually isn't. This allows Flash to think that it's doing its thing while we fool it by feeding it what it thinks it wants to see. Flash ends up fat, dumb and happy not even knowing that it's not really living in our kernel. The end result is that there are many layers between Flash and the KNOS core (BSD) through which all of that Flash content must travel in order to appear in the browser at all. So clearly, with all these extra layers, Flash is going to be slower than it would be in a native Linux environment. However, thanks to the benefits of the far smaller amount of spaghetti in KNOS' BSD core, the detremental effects of all that of redirecting is minimized. That's why it manages to work despite all of our brick walls between it and our system. Like I said, this aspect alone is what took us and others nearly two years.

In your case, to add to all the fun, NVIDIA also insists on their own proprietary world of reaching deeply into an operating system's kernel and exposing security risks of their own which fortunately pale to those of Adobe. KNOS is designed to be as generic as possible in our "public" design so that it can pretty much run on anything without requiring the download and installation of special drivers for a specific machine. And when NVIDIA cards are run at resolutions up to 1440x900 using our generic driver, no problem. When you start getting into much higher resolutions however, then the prorietary NVIDIA drivers are required in order to invoke their proprietary "hardware acceleration" which would obviate that problem. Without that "hardware acceleration" the CPU in the box is doing all the rendering work instead of the video card. A custom version of KNOS for a "known machine" would include those proprietary drivers which NVIDIA has made available to us only recently. However, use of those NVIDIA drivers would cause KNOS to have problems with any other video card's chipsets since NVIDIA requires some really squirrely calls. Thus hopefully when we have time, we can build one of these generic KNOS versions specifically for those with NVIDIA cards, but then the end user would need to know what hardware they have to download that special version. For now, we wanted to avoid that. But it's not a problem for us if we know the machine is running NVIDIA, we can build that!

Finally, Firefox itself has gotten "insane bloated" and inefficient. That TOO adds to the delays you're seeing. In a windowed display in the browser, we're not requiring headroom above the processor's natural clock rate, and in most modern machines even this isn't a problem and the symptoms won't appear even at your resolution. But if the box is a little older, a little slower, then it will at that resolution for all the reasons above. And Firefox contributes to the mess with all the noise it's making in the background while you're surfing.

Just for laughs and giggles, try our Epiphany browser (it's HTML5 and still needs a bit of work, but it's similar in design to Safari or Chrome!) and go back there and give it a shot. I'd be willing to bet that just losing Firefox' bad code will make up the difference sufficiently for a win. Figured I'd take this chance though to explain it all because for the past two years and change, Adobe's been a frigging nightmare and I can't wait to see HTML5 end that torture for all involved!

[joncrndl]

Thank-you! that explains a lot! I do have KNOS64 running very well from the SanDisk Cruz stick for testing Flash full screen to minimize the overhead of going to the DVD.

I now understand why Flash does generally run better on the Ubuntu branch.

Let me know if you want to test the Nvidia video driver. The Linux implementation of the Nvidia driver has improved greatly over the past 2 years since I got this laptop.

[Kevin McAleavey]

Feb 21, 2011 11:27:22 GMT -5 joncrndl said:

Thank-you! that explains a lot! I do have KNOS64 running very well from the SanDisk Cruz stick for testing Flash full screen to minimize the overhead of going to the DVD.

I now understand why Flash does generally run better on the Ubuntu branch.

Let me know if you want to test the Nvidia video driver. The Linux implementation of the Nvidia driver has improved greatly over the past 2 years since I got this laptop.

One of the major reasons we built KNOS with BSD to start with was not being trapped in the GNU licensing restrictions. That permits us to enter into agreements with manufacturers to use their proprietary code (for a fee and non-disclosure) down the road when we can afford to enter into such agreements. One of the problems with NVidia video is that they currently have seven completely different (and incompatible with each other) libraries for their drivers which will require seven different versions for extremely specific cards ... for an end user, that will get extremely messy. That's a no-go in my book.

Now if a computer distributor had a specific model that they wanted to distribute KNOS on (or a company with a standard purchase in bulk) then this all gets very easy of course because we can put together a build for one specific machine type. But currently, our limitations make that expensive and difficult for our site as well as ensuring that each downloader would end up with the correct NVidia drivers. Once we get our own distribution together and can afford to do so, we want to work with NVidia on unifying those drivers so that everything can go into a single core version.

Unlike Windows, we don't want to distribute a barebones version and then let the end user or computer system integrator have to suffer with downloading and installing drivers, configuring them and then having to deal with all sorts of headaches just to get the machine running. Once we get things going on the next build (BSD just released their 8.2 release version over the weekend) we'll see about building that in for our next and hopefully final RC2. Stay tuned.