OK, so I'll assume that you are referring to another recent discussion about gaming performance.
1. Yes, we care about UI performance, and more generally we care about situations where apps "hurt" one another. 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). 3. Sorry, not an engineering question, we've already established that I can't answer that one. 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. 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. About my example: I hadn't reached the implementation phase yet, that specific issue is still very firmly in the design phase. JBQ On Fri, Mar 27, 2009 at 1:30 PM, Stoyan Damov <[email protected]> wrote: > > On Fri, Mar 27, 2009 at 9:51 PM, Jean-Baptiste Queru <[email protected]> wrote: >> >> My question is, what part of the system do you want somebody's thoughts >> about? > > We would like: > > 1. To know whether you're on our page, and want to provide the best > possible experience for the foreground application currently launched, > w/o sacrificing entirely any background stuff, or you think that "hey, > the user has a nice multi-tasking OS, he can launch so many apps > simultaneously, who cares he can't run a game, or another demanding > app at full speed?" > > 2. To know, if you're on our page, what are you planning on doing to > solve the problem, and "we're working on it" is not an answer. > Implementation details are not important, but a coarse grained > explanation on the design of the feature is a good start. > > 3. A roadmap of what Google is planning as features for next releases of the > OS. > > 4. A way for us, developers, *and* users, to give suggestions on 2, > and 3, and I can tell you that a bug report page is not good. > > 5. Assurance, that this is indeed a community project, we're welcome > to participate in many ways, including ideas, and not just code > contributions, and when we do, we'd like to not feel like we're > trolls, though we (me in particular) do sound like ones occasionally. > >> >> Let's go super-precise: > > Let's not. That's exactly what is not necessary. I wouldn't *ever* > tell a developer how to implement anything if we've agreed on the > design, and he knows what he's doing. Nobody on this list has the > slightest doubt that you're exceptional developers, and that > implementation details should not be discussed, because it's > insulting. > > Cheers > > > > -- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google. Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
