banryu79
22-07-2010, 14:54
Salve,
ho un'implementazione casereccia di un JFrame che usa un content pane customizzato in modo tale da sembrare trasparente.
Il content pane in pratica, fa una "foto" del desktop e la usa, traslata a dovere, come sfondo del frame.
Ovviamente allo scatenarsi di certi eventi è neccessario "rifotografare" il desktop per aggiornare lo sfondo, in modo che tutto sembri sempre coerente.
Tralasciando questioni secondarie, la classe che implementa questo content pane "trasparente" è dotata di una classe interna ScreenshotUpdater, che in pratica è un thread che ciclicamente controlla se è neccessario fare la nuova foto al desktop, e in tale caso deve:
1 - spostare il frame trasparente fuori dall'area visibile dello schermo;
2 - fare la foto allo schermo;
3 - rimettere il frame dove si trovava.
Io eseguo il punto 1 accodando l'operazione nell'EDT con SwingUtilities.invokeAndWait() e la mia aspettativa era che tale operazione venisse completata in toto (frame *effettivamente* mosso) prima che venisse eseguito il punto 2, ma pare non sia *sempre* così.
Per ovviare ho dovuto aggiungere tra 1 e 2 una chiamata a sleep sul thread corrente.
Questo è il codice (in marroncino la parte contingente, il resto serve per capire il contesto):
/**
* Encapsulate calls on the EDT to setLocation.
* Used to move the frame associated with this
* component out of visible desktop area before
* taking a screenshot.
*/
class SetLocationCaller implements Runnable
{
final int X;
final int Y;
SetLocationCaller(Point p) {
this(p.x, p.y);
}
SetLocationCaller(int x, int y) {
X = x;
Y = y;
}
public void run() {
frame.setLocation(X, Y);
}
}
// TASK: Improve ScreenshotUpdater
// Also all frame children of this 'frame' must be considered
// when moving out of desktop visible area at snapshot-time.
/**
* Used to encapsulate the task of taking a screenshot.
* It should always run out of the EDT, and need to syncrho/wait
* correctly with SetLocationCaller, for taking snapshot correctly.
*/
class ScreenshotUpdater implements Runnable
{
SetLocationCaller moveBack, moveOut;
private void pauseThread(long millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException ignored) {}
}
public void run() {
while (frameIsNotClosing) {
pauseThread(75);
long now = System.currentTimeMillis();
if (refreshRequested && ((now - lastUpdate) > 500)) {
if (frame.isVisible()) {
moveBack = new SetLocationCaller(frame.getLocation());
moveOut = new SetLocationCaller(-frame.getWidth(),
-frame.getHeight());
try {
SwingUtilities.invokeAndWait(moveOut);
} catch (Exception ignored) {}
pauseThread(10); // nedeed, invokeAndWait it's not enough!
takeScreenSnapshot();
SwingUtilities.invokeLater(moveBack);
}
lastUpdate = now;
refreshRequested = false;
}
}
}
}
Ma invokeAndWait non è bloccante?
E il run() del runnable che esegue dovrebbe venire eseguito tutto; l'unica cosa che fa è una chiamata a setLocation: ho provato a cercare nei sorgenti per vedere se setLocation non combinasse qualcosa di strano (magari l'esecuzione effettiva è asincrona) ma non ne sono venuto a capo.
Qualcuno vede l'errore?
ho un'implementazione casereccia di un JFrame che usa un content pane customizzato in modo tale da sembrare trasparente.
Il content pane in pratica, fa una "foto" del desktop e la usa, traslata a dovere, come sfondo del frame.
Ovviamente allo scatenarsi di certi eventi è neccessario "rifotografare" il desktop per aggiornare lo sfondo, in modo che tutto sembri sempre coerente.
Tralasciando questioni secondarie, la classe che implementa questo content pane "trasparente" è dotata di una classe interna ScreenshotUpdater, che in pratica è un thread che ciclicamente controlla se è neccessario fare la nuova foto al desktop, e in tale caso deve:
1 - spostare il frame trasparente fuori dall'area visibile dello schermo;
2 - fare la foto allo schermo;
3 - rimettere il frame dove si trovava.
Io eseguo il punto 1 accodando l'operazione nell'EDT con SwingUtilities.invokeAndWait() e la mia aspettativa era che tale operazione venisse completata in toto (frame *effettivamente* mosso) prima che venisse eseguito il punto 2, ma pare non sia *sempre* così.
Per ovviare ho dovuto aggiungere tra 1 e 2 una chiamata a sleep sul thread corrente.
Questo è il codice (in marroncino la parte contingente, il resto serve per capire il contesto):
/**
* Encapsulate calls on the EDT to setLocation.
* Used to move the frame associated with this
* component out of visible desktop area before
* taking a screenshot.
*/
class SetLocationCaller implements Runnable
{
final int X;
final int Y;
SetLocationCaller(Point p) {
this(p.x, p.y);
}
SetLocationCaller(int x, int y) {
X = x;
Y = y;
}
public void run() {
frame.setLocation(X, Y);
}
}
// TASK: Improve ScreenshotUpdater
// Also all frame children of this 'frame' must be considered
// when moving out of desktop visible area at snapshot-time.
/**
* Used to encapsulate the task of taking a screenshot.
* It should always run out of the EDT, and need to syncrho/wait
* correctly with SetLocationCaller, for taking snapshot correctly.
*/
class ScreenshotUpdater implements Runnable
{
SetLocationCaller moveBack, moveOut;
private void pauseThread(long millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException ignored) {}
}
public void run() {
while (frameIsNotClosing) {
pauseThread(75);
long now = System.currentTimeMillis();
if (refreshRequested && ((now - lastUpdate) > 500)) {
if (frame.isVisible()) {
moveBack = new SetLocationCaller(frame.getLocation());
moveOut = new SetLocationCaller(-frame.getWidth(),
-frame.getHeight());
try {
SwingUtilities.invokeAndWait(moveOut);
} catch (Exception ignored) {}
pauseThread(10); // nedeed, invokeAndWait it's not enough!
takeScreenSnapshot();
SwingUtilities.invokeLater(moveBack);
}
lastUpdate = now;
refreshRequested = false;
}
}
}
}
Ma invokeAndWait non è bloccante?
E il run() del runnable che esegue dovrebbe venire eseguito tutto; l'unica cosa che fa è una chiamata a setLocation: ho provato a cercare nei sorgenti per vedere se setLocation non combinasse qualcosa di strano (magari l'esecuzione effettiva è asincrona) ma non ne sono venuto a capo.
Qualcuno vede l'errore?