Cache:true ... otro detalle para mejorar el rendimiento gráfico

Si, por ejemplo, utilizas una figura con una gradiente -o sombra- como fondo de un área, es mejor agregar a esa figura el parámetro cache:true, de manera de evitar que el objeto sea re-dibujado con cada cambio que se realiza por encima de él (en el caso de una gradiente, debe volver a recalcular y redibujar cada franja de color que conforma la transición entre los colores... lo que resulta sumamente "caro" en términos de procesamiento).

El código al pie del artículo

Al agregar cache:true se le indica al sistema que debe generar la imagen una vez y guardarla en cache, de esta menera, cuando se realiza un cambio sobre ella, sólo recupera la imagen desde una copia almacenada en memoria (como bytes) y pinta los cambios encima, lo que resulta sumamente rápido y menos "costoso" en ciclos de procesamiento.

En todo caso, no debes utilizar cache:true cuando la imagen va a cambiar con frecuencia, porque esto sólo producirá que sea re-generada con cada cambio, pero además almacenada, lo que da por resultado un proceso mucho más "costoso". El cache:true debe ser utilizado en imágenes que NO cambian frecuentemente.

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.shape.Rectangle;
import javafx.scene.paint.Color;
import javafx.scene.paint.LinearGradient;
import javafx.scene.paint.Stop;
import javafx.animation.Timeline;
import javafx.animation.KeyFrame;
import javafx.scene.effect.DropShadow;

var px:Number;
var py:Number;
Timeline {
    repeatCount: Timeline.INDEFINITE
    autoReverse:true
    keyFrames : [
        KeyFrame {
            time : 0s
            values: [px=>100, py=>100]
        }
        KeyFrame {
            time : 3s
            canSkip : true
            values: [px=>1180, py=>680]
        }
    ]
}.play();

var angle:Number;
Timeline {
    repeatCount: Timeline.INDEFINITE
    autoReverse:true
    keyFrames : [
        KeyFrame {
            time : 0s
            values: [angle=>0]
        }
        KeyFrame {
            time : 1.5s
            canSkip : true
            values: [angle=>360]
        }
    ]
}.play();

Stage {
    title: "Application title"
    width: 1024
    height: 768
    scene: Scene {
        content: [
            Rectangle {
                cache:true
                x: 0, y: 0
                width: 1280, height: 768
                fill: LinearGradient {
                    startX : 0.0
                    startY : 0.0
                    endX : 1.0
                    endY : 0.0
                    stops: [
                        Stop {
                            color : Color.BLACK
                            offset: 0.0
                        },
                        Stop {
                            color : Color.BLUE
                            offset: 1.0
                        },

                    ]
                }
                effect: DropShadow { offsetX:10, offsetY:10 }
            }
            Rectangle {
                x: bind px, y: bind py
                width: 200, height: 200
                fill: Color.RED
                rotate: bind angle
            }

        ]
    }
}

Un detalle para obtener una mejor performance

Este detalle (junto con incluir canSkip:true en los timelines asociados a animaciones o transiciones gráficas de algún tipo) puede hacer una gran diferencia en la performance gráfica de JavaFX.



Tengo un CustomNode cuyo contenido son unos nodos almacenados en una secuencia:

public class myComponent extends CustomNode {

    var objs:Node[];

    public override function create(): Node {
        Group {
            content: bind objs
        };
    };
}

Digamos que se necesita reemplazar con frecuencia los nodos en objs y que tengo una función que realiza este trabajo:

function paint():Void {

    delete objs;

    for (element in someGroup) {
        ...
        insert newNode into objs;
        ...
    }
}

Como muestra el video, eso es ineficiente. Al estar enlazado el contenido de objs con el contenido del componente e ir cambiando el contenido de objs, se va gatillando trabajo para refrescar el componente.

Es más eficiente crear una secuencia temporal y traspasar al final todos los nodos a la secuencia asociada al componente:

function paint():Void {

    var tmpObjs:Node[];

    for (element in someGroup) {
        ...
        insert newNode into tmpObjs;
        ...
    }
    
    objs = tmpObjs;
}

Habría que probar si esto también es aplicable cuando se realizan cambios a los elementos en la secuencia (y no sólo cuando estos se reemplazan). Es probable que ocurra lo mismo, porque al actualizar uno a uno los elementos, es muy probable que también se vaya gatillando trabajo parcial, mientras si se reemplaza toda la secuencia de una vez, ese trabajo debería ocurrir una sóla vez... ¿?

Cómo compilar clases Java en JavaFX, que contienen delete o insert

Como saben, los términos "insert" y "delete" están reservados por JavaFX para insertar y borrar elementos en las secuencias. Esto puede producir un inconveniente cuando uno incluye dentro de un proyecto JavaFX una clase Java donde se utiliza llamadas a métodos denominados "insert" o "delete".

Esto ocurre, por ejemplo, si se utiliza "delete" para borrar un archivo. El compilador muestra el siguiente error:

Sorry, I was trying to understand an expression
but I got confused when I saw 'delete' which is a keyword.
new java.io.File("temp").delete();
                         ^

La solución es simple, sólo hay que incluir el término entre << ... >>

new java.io.File("temp").<<delete>>();

Lo interesante es que esta sintaxis permite utilizar cualquier texto como un identificador:

def <<english
      variable>> = "cualquier simbolo sirve como identificador";
def <<русская переменная>> = <<english
      variable>>;
println(<<русская переменная>>);

La salida del script es:

cualquier simbolo sirve como identificador

Noten que el identificador "english variable" incluso incluye un salto de línea (CR/LF).

Usando FX.deferAction()

Al desarrollar el componente de acordeón de imágenes, se producía un "pestañeo extraño" al momento de solicitar a los elementos que actualizaran su posición. Le dí algunas vueltas al código hasta comprobar que: no era resultado de algo producido por un error en el código, sino por algo relacionado con el refresco de la pantalla (o algo por el estilo ¿?).

Así que recurrí un poco al instinto y a la memoria... y... recorde haber leido algo sobre deferAction. Así que incluí el código que solicita el ajuste de posición, dentro de la llamada de esta función y el problema terminó:

El siguiente código:

public-read var active: Integer on replace {       
    for (item in pictures) {
        item.adjust();
    };
};

Pasó a ser este:

public-read var active: Integer on replace {
    FX.deferAction(function():Void {
        for (item in pictures) {
            item.adjust();
        };
    });
};

Sólo anidé el for dentro de FX.deferAction(function():Void { ... });

Sí descargan la biblioteca memeFX y quitan el FX.deferAction en ImagesAccordion.fx, quizás puedan ver el problema que me llevó a esta solución (no sé si el problema sea reproducible en otras máquinas). Tampoco me quedó claro que produce el problema ni por qué lo resuelve deferAction, voy a buscar información al respecto. Por ahora, sólo comparto el "tip" en caso que alguien tenga un problema similar.

http://code.google.com/p/memefx/

Un pequeño bug en el Timeline y una solución

Estaba haciendo unas pruebas y de vez en cuando notaba un comportamiento extraño, finalmente descubrí que el problema se origina en la reutilización de un Timeline, que estaba definido como:

    var timeline= Timeline {
        repeatCount: 1
        keyFrames: [
            at (0s) { currentX => startX }
            at (0.5s) { currentX => posX }
        ]
    };

Aunque no es el ideal que haya bugs, es algo habitual en una plataforma nueva (he leído que Adobe Flex tiene demasiados bugs, así que -aunque es consuelo de tontos- me voy a conformar con este pequeño error en JavaFX).

La solución fue tan simple como... no reutilizar el Timeline una y otra vez, sino que recrearlo cuando lo voy a usar:

    var timeline:Timeline;

...

            timeline = Timeline {
                repeatCount: 1
                keyFrames: [
                    at (0s) { currentX => startX }
                    at (0.5s) { currentX => posX }
                ]
            };
            timeline.playFromStart();

El problema específico de mi programa, era que a veces asignaba currentX igual a 0 en at (0s), aunque startX no tenia ese valor.

En todo caso, no es un problema que ocurra con frecuencia (supongo que debe ser un pequeño error el compilador), así que no es necesario hacer esto cada vez que utilicen un Timeline... pero si notan algo extraño como que un elemento asociado de alguna manera a un timeline salta de manera no esperada, intenten esto (por lo menos hasta que el bug sea corregido).