[T-Mobile myTouch 4G Slide] Blue6IX:
Okay - now you're digging into the point of me putting all this work into setting up the ROM and turning around to work on kernels.

Let me skip to the part where you touch on TV-out. It's the reason I bought the phone, which i've made no secret about. Also that it's my mission to have Sense TV-out with a sixaxis bluetooth controller to play video games with. It's what the device was designed to do, and what I bought it for, and dammit - I don't care how much code I have to write for this device, I will have the satisfaction of achieving that goal.

...the idea of writing bluetooth drivers from scratch is not off the table, as ludacris as that sounds...

(whew - lol :D:p )

That all being said, first things first - TV-out. I noticed very early on, back when I first got the phone, that it got skippy and laggy without using an app that enables software decoding.

At first I attributed it to the unfinished, unmentioned nature of the TV-out capabilities of the device. Now, though, i'm not so sure.

I've spent a lot of time browsing all over XDA, reading offsite technical manuals and just basically studying android and how it works. Getting this device was a dedicated leap off the side of the pool, to get my hands dirty and really learn Android. It's amazing how much misinformation is passed around, even in XDA.

Before you can solve the TV-out lag issue, you have to know how Android uses the GPU and what other things it's doing when you go to use it for something as large and long as a movie.

A lot of small things are done by the operating system using the GPU, and until you really start to find out what they are and how much/frequently it's accessed you really don't realize it's not just a 'spare part' waiting to be used. It IS being used, quite consistently.

Too, also, a lot of apps - especially older ones - aren't set up to handle hadware graphics rendering. They could not work at all when forced to do so, but most likely will just act pretty weird until/if they force close.

Hardware rendering as an Android implemented capability/function wasn't really available/implemented well before 3.0 as I understand it...though Android used it frequently, it didn't share well with the apps it was running.

( I'm still pretty new to the whole Android experience, so learning my history of it's development has been split between learning what's happening right now )

One of the reasons this ROM runs so smoothly is the balance that's struck between hardware/software rendering. This is the part where I started to contribute to what Roman was building when I started really digging in and fixed the TV-out bug you may have read about in the pre-1.0 thread.

Solving that issue set the tone for the rest of the way I have been interacting with the ROM from then on. ( Yay, at the beginning! ) Each move I make is a tentative step towards greater efficiency towards how the device interacts with itself.

On any computer system, memory management is ( or should be! ) your single greatest area of concentration to ensure everything runs smooth. You always want to have what you need when you need it, and not have to wait for something else to finish before you can do your thing.

Taking this a step further, you want to balance your hardware and software rendering operations so that whatever one you try to use will have the most minimal impact on the system as possible.

This isn't as easy as it sounds, though. While I have the system set to try to default to software rendering first it's not some immutable rule. It's actually quite easily overruled, and app can just decide to use hardware rendering without incident - so go ahead and play with it.

When you see the 1.1 release ( yeah, I promise as fast as I can! ) you will notice a bunch of UI changes, including an almost fully set default theme. This isn't just a theme that's been made to look pretty -( though it is that too! )- i've changed a lot of the graphics around for a utility purpose. It lets me exert some control over when certain functions are using the GPU or just being software rendered.

It may not seem like much, but you'd be surprised at how much nicer things run when you start manually directing traffic.

From a user standpoint

, you should never use a task killer. Android is taking care of you, don't worry about it and just use the device.

From the standpoint of a user using Bulletproof, this goes double.

I'm doing a lot of things to manage memory and processor time and availability that you can't see or won't realize.

If you use a task killer, you will really cause a traffic jam on your device, prevent data from being saved and generally muck up the balance i'm striking for performance.

----

Okay, now lets get back to your question about the dual-core processor and what's using it and when.

Now that we know a little more about how the CPU, GPU and RAM work together, we've learned that an app can't use hardware rendering if it wasn't explicitly designed to do so. ( *changing with ICS )

Ditto for apps that weren't made to utilize a dual-core system. To some extent Android will fire up the second CPU if you haven't restricted it from doing so, but unless an app was specifically designed for a dual-core system it's not using anywhere near your money's worth of computing potential.

Again, this is changing with the hardware availability and the native abilities of Android itself growing, but it's all still in it's infancy and we have to make to with a lot of tricks and tweaks to make everything run right.

It's all a matter of balancing the load on the system so it's as evenly distributed as possible. There are many different ways of approaching this, and through the iterations of Bulletproof here we're gonna see how far we can push this device.

The doubleshot is built very well, and has the perfect mix of features to become something I just couldn't pass up. I have two of them now, if that lends any more weight to my statement.

Getting back to the GPU again for a minute - the MT4GS has a sleeper asset that gives it an edge in computing power. The screen size. Everyone is on the 'bigger is better' page - when it's not, not by a long shot.

A bigger screen means more redraws over a larger range of pixels, requiring more CPU/GPU time/cycles and memory usage. The smaller screen of the doubleshot means it gets the same work done with less effort.

( Besides, I have a laptop already - lol )

You've been hearing me say how i've been wanting to build a ROM to test some kernel work in, and that was in part because of the education I needed in building the ROM, and in part to have something to test the kernels IN.

We are cruising along and i'm making some swift strides because of the round-the-clock obsession this has become. I like being able to completely immerse myself in a learning experience and XDA has been - well, words can't describe how fantastic of a developers resource XDA is.

This is why I need all of you to keep reporting in about how things are going using the phones in the field, and what apps your running and so forth. The more data I have about how people are using the devices, the more I can streamline the operations of it's operating system.

I have a good idea of what i've got to do, even through the obvious and blatant holes in my self-education. I've been picking up everything pretty quickly, again because of the time invested. It's just becoming more and more instinctive and natural, I literally see it happening in front of me.

--------

I know it seems like a lot of talk with no tangible results posted yet, but since everyone is okay with wiping and starting fresh on 1.1 i'm handling all the planned future overhauls to core systems right now, instead of slowly over patches. I know what I want for a lot of things, and if I do it right now it'll make life a whole lot easier on everyone.

Most of the core is taken care of, I have a couple of minor things to do yet and one issue waiting for me to figure out how to solve it when I get there ( almost there ) and then it's into testing, final tweaking, then release.

So far i've been working at a furious pace, yet taking my time. By doing things in a steady, systematic order and incrementing changes with lots of testing even when i've run into problems it's been real easy to take a step or three backwards and try a different approach without losing too much time. No more then the learning experience was worth, anyways :cool:

Just because i'm working quick doesn't mean i'm rushing - big difference. Big fan over here of taking the extra time to do something completely and right. I've already chosen to do whatever task is in front of me, why should each one not be to the best of my ability?

It's mind-numbingly tedious to go through the graphics and animations that come out of the box. All different types of images, some that really took some doing to figure out how to work with, and then on to work with the right way.

I'll confess, I absolutely hate graphics work. That's one of those things that i've invested the money into buying a good program for (photoshop) because I don't want to have to fight with my tools to get the job done, whatever that job may end up being.

Photoshop is the swiss-army knife of graphics programs. My version is kind of older now, and I have no desire to upgrade or change it. It does what I need, I know how to find what I need in it, and I already hate having to use it so being more confused then I already am is a recipe for disaster. I may not know how to use it well, but I can get done or find out how to do what I need in relatively short order.

My graphics work isn't the flashiest or most impressive, but anything I do will be neat and nice at least. Maybe not the most interesting, but my standard is neat and clean - not wow.

I know I rambled a bit and wandered over a range of stuff in there - which is my way I suppose, but you can see how it all ties into itself.

The GPU issue isn't black and white, the dual-processor capability of the device isn't necessarily always running (...and yes, this is a good thing) and forcing myself to slave through the graphics work i'm almost completely finished is actually an integral step on the flowchart i've written for the planned evolution of Bulletproof on the doubleshot.

I have a lot of work mapped out, more then I have time to do, so it's been a matter of taking the biggest steps possible towards minimizing the file size of future updates and downloads, while keeping it running smooth by not getting ahead of what it can do.

( Gotta maximize stock potential before taking it into overclock. Can't exceed your ceiling if you don't know what it is. )

I wish I had someone out here in the physical world I could sit down and work with or talk about this kind of stuff with. I'm consuming and juggling so much information that when I stop to post something I end up basically doing a small RAM dump into the thread.