Esto sucede en varios contextos de Java pero en la promgracion de GUI'S es donde es mas evidente. Los disenadores de Java querian que cualquier programa pudiera correr en cualquier maquina que tuviera una Java VM.
Por lo tanto, un programa en particular podria estar ejecutandose en una maquina de escritorio o un portatil, o una ipad o en un telefono. Esto representa un desafio para el disenador que use AWT Tambien hace que el trabajo de un programador novato sea mas complicado de lo que podria ser. Asi son las cosas.
Evolucion del sistema de pintado en swing
Cuando el API original de AWT fue desarrollado para el JDK 1.0, unicamente existian componentes pesados ("heavyweight") Esto obligo al AWT a depender del subsistema de pintado nativo de cada plataforma. Este subsistema se hizo cargo de los detalles tales como la deteccion de danos, el calculo del clip, y el ordenamiento de componentes. Con la introducion de los componentes ligeros en JDK 1.1 el AWT necesito implementar el proceso de pintado para los componentes ligeros. En consecuencia, hay diferencias sutiles en la forma del pintado entre los componentes ligeros y los pesados.
Despues del JDK 1.1 cuando el toolkit de Swing fue liberado, definio su forma de pintar los componentes. En su mayor parte, el mecanismo de pintado se asemeja a la del AWT. Pero tambien presenta algunas diferencias en el mecanismo, asi como nuevas APIs que hacen mas facil el proceso de pintado.
Pintando en AWT
Para comprender como el API AWT realiza el proceso de pintado, vamos a conocer las razones por las que se dispara una accion de pintado en una ventana. En AWT, hay dos tipos de operaciones de pintado: disparados por el sistema
1) public void update(Graphics g)
Rellena el area dibujable de un componente con su color de fondo y entonces llama a paint(Graphics g) del objeto. Por lo tanto, el parpadeo que viene de volver a dibujar el fondo una y otra vez a veces puede ser fixeado sobreescribiendo el metodo update( )
Referencia
https://www.oracle.com/java/technologies/painting.html
