On Fri, Mar 27, 2009 at 10:49 PM, Jean-Baptiste Queru <[email protected]> wrote: > > OK, so I'll assume that you are referring to another recent discussion > about gaming performance.
Right. > > 1. Yes, we care about UI performance, and more generally we care about > situations where apps "hurt" one another. And *especially* when a background app is hurting a foreground app? I can't find anyone would want a background service to get more cycles than the currently executing UI in the foreground, because the UI pegs the CPU and is thus "hurting" the background service, right? Right? > 2. It's not my domain, and I'm pretty sure that the people whose > domain it is aren't reading that list. I've heard talk about using > scheduler groups (or are they called scheduler classes or something > else?) to deal with the notion of apps moving in and out of being in > the foreground. I've also heard some investigation around I/O > (prioritizing I/O based on thread priorities - as unfortunately it > looks like yaff2/mtd are fundamentally serialized). Do these people read any of the android-* lists, and if yes, which ones? If you don't know the answer to any of the 2 questions, how can we make contact with these people? > 3. Sorry, not an engineering question, we've already established that > I can't answer that one. I don't want you to answer it either. I would love though, if you could point us to someone who could, or would. > 4. I'm afraid that we've got to agree to disagree here, as I believe > that a bug report is the right place to store that information if > you're not going to personally actively work on the implementation, so > that much later when someone works on it they can have your input even > if you're not around. OK. We agree to disagree. I do want ideas and suggestions to be logged for future reading. I mind the bug-tracking system. I would imagine something like a web site, where people could post ideas and suggestions, and others can vote, and comment on them, tag them, search them easily, etc. http://code.google.com/p/android/issues/list is simply not appropriate. > 5. If you don't want to be explicitly writing code but still have > something to contribute, read android-platform, and when someone > discusses something that you have relevant experience about (and can > get yourself to not consider everyone else an idiot) you can bring in > your contribution. If an issue isn't actively worked on at the moment > and is already reported in the bug database, you can add your input > there. So android-platform is the right list for this, ok, thanks. > About my example: I hadn't reached the implementation phase yet, that > specific issue is still very firmly in the design phase. > Screw the HTTP-date thing, do us all a favor and implement screenshots for the Market application ;) Chees --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
