Cita: Originalmente Escrito por
83266
Se que tendria que ser por privado, pero no se por que no me deja, nunca lo he usado y ahora que quiero usarlo no puedo, pero bueno te lo digo por aqui.
la linea es windowssmgr.max_events_per_sec=(cuanto mas alto el valor mas rapido responde el tactil) yo lo he puesto en el mod a 150 que ya esta bien, pero en el wildfire s que tenia antes lo he llevado a 300 y funcionando de maravilla.
Os pongo lo que he encontrado al respecto:
-------------------------------------------------
http://www.jeffmixon.com/examining-b...-guide-part-1
-------------------------------------------------
windowsmgr.max_events_per_sec – BUSTED
As the name implies, this property specifies how quickly the system is allowed to process certain events before throttling occurs. Specifically, this property is used by the
InputDispatcher when processing screen touch and movement events. This value will really only come in to play with extremely rapid touch events, such as swiping or scrolling. The default value for this property is 90, and Google explains why:
// This number equates to the refresh rate * 1.5. The rate should be at least // equal to the screen refresh rate. We increase the rate by 50% to compensate for // the discontinuity between the actual rate that events come in at (they do // not necessarily come in constantly and are not handled synchronously). // Ideally, we would use Display.getRefreshRate(), but as this does not necessarily // return a sensible result, we use '60' as our default assumed refresh rate. result
= 90;
Many build.prop tweaks set this value to 300, but it seems this is a bad idea. As Google points out, Android maxes out at 60fps. The default value is already allow for a possible max_events_per_sec of 90. Even if you allow for 300 max_events_per_sec, you’ll only ever see 60 of these events in any given second. Therefore, any value much higher than 90 is unlikely to have any noticeable impact on your experience in general. Additionally, setting this value too high can starve other UI events that need to get processed, viz. touch inputs. You’re not likely to feel like your device is running very smoothly when it is busy processing thousands of scroll events instead of responding immediately to you clicking to try and open a link or an app. There may be some specific scenarios where increasing this value does appear to improve system feedback, but changing this value for all UI events across the board will likely cause more problems than it will solve.
-------------------------------------------------
Vienen a decir que google recomienda poner 90 en este valor, porque calcula el refresco de la pantalla (60 fps), multiplicado por 1,5 lo que compensa el retardo que pueda haber por otras aplicaciones. El subir el valor a 300, es multiplicar por cinco el refresco, lo que hace que otras aplicaciones que necesiten procesador no lo tengan disponible por que el móvil está ocupado leyendo la pantalla.
Es decir, que si subes el refresco, bajas rendimiento general del aparato.
Es como lo del volumen... Si, lo pones a 40 y suena de narices... hasta que peta el altavoz. Aconsejo ser conservador, y no modificar los valores por defecto más allá de un 10-20% del inicial. Forzar, puede ser una fuente de cuelgues continuos, o peor de fallos de hardware.
Un saludo.