2012-03-25 25 views
6

Tengo varias vistas dentro de un FrameLayout. Hay una transición que he escrito donde cada vista tiene una clase de animación personalizada aplicada. Durante esta transición, necesito llevar la Vista en la parte inferior del orden Z al frente. Hago esto con:Android View.bringToFront() causa parpadeo

public static void putBackAtFront(ViewGroup v) 
    { 
     v.getChildAt(0).bringToFront(); 
     refreshEverything(v); 
    } 

Esto se llama desde el applyTransformation() de mi Animación personalizada.

decir

public class PivotAnimation extends Animation { 
    private View view; 
    ... 
    @Override 
    protected void applyTransformation(float interpolatedTime, Transformation t) 
    { 
     ... 
     if(interpolatedTime >= 1.f && isAtBack(view)) 
     { 
      putBackAtFront(view); 
     } 
     ... 
    } 
    ... 
} 

refreshEverything (llamadas) invalidan() y requestLayout() en la matriz FrameLayout y todos sus hijos.

Todo funciona a la perfección, excepto que cuando se invoca putBackAtFront(), la vista que ahora está en la parte inferior desaparece para un solo fotograma antes de volver a aparecer instantáneamente, lo que produce un parpadeo notable. También lo intenté sin llamar a refreshEverything(), no hace ninguna diferencia.

estoy focalización API Nivel 7.

Respuesta

1

applyTransformation() se llama varias veces durante la animación por lo que debe hacer la animación basada en la interpolatedTime, cuando su 1.0, la animación está en el extremo, por lo que debe llamar a su traer al frente aquí.

En mi opinión, este parpadeo ocurre cuando en algunas de estas llamadas a su método, getChildAt (0) obtiene una vista diferente a la que desea y aparece el parpadeo.

+0

Lo siento, he actualizado mi pregunta para aclarar. Ya estoy haciendo lo que dices; putBackAtFront() solo se llama una vez al final de la transición, no siempre. –

0

Estoy pensando que tiene que ser una de tres cosas:

Si usted está construyendo con las APIs 3.0+, es posible que tenga activada la aceleración de hardware. Esto también está activado por defecto en 4.0. Puede intentar usar

setLayerType(LAYER_TYPE_SOFTWARE, null); 

para deshabilitar la aceleración HW en ese diseño/vista/ventana.

Además, puede que no necesite llamar al requestLayout(), si todas las vistas son secundarias de un diseño relativo, un cambio del índice Z no debería preocuparlo.

La llamada invalida casi no es necesaria. ¿Ha intentado hacer las Vistas enfocables y simplemente llamando al requestFocus() en lugar de bringToFront() en absoluto? bringToFront() aparentemente elimina la vista de su principal y la vuelve a agregar. Esto podría fácilmente causar una invalidación entre los pasos, ya que no creo que nada esté deteniendo el dibujo mientras esto sucede.

+0

Gracias por las sugerencias. Como se indica en la pregunta, apuntaré a API 7 (2.1), por lo que la aceleración de HW no es una opción para mí. requestFocus() no cambiará el orden z, que necesito que suceda. También como se indica en la pregunta que he intentado con y sin requestLayout() e invalidar(). En cualquier caso, se llama a bringToFront() en el subproceso de la IU (principal), por lo que, de acuerdo con los documentos, por definición, "se debe pausar" el dibujo. A menos que los documentos no cuenten la historia completa, y hay una representación asincrónica pasando. –

Cuestiones relacionadas