Applet scherm wissen?

[Verwijderd]

Hoi. Ik ben bezig aan een klein Java applet. Het is een screensaver. Binnen de grenzen van een java applet moet een vierkant heen en weer stuiteren. Dit doe ik door de x en y positie van een gDrawrect aan te passen in een infinite loop. Ik wil echter ALLEEN het laatst getekende vierkant zien en niet het spoor van alle vierkanten die al getekend zijn. Met andere woorden: "Hoe kan ik het scherm leegmaken in de Graphics() methode?

[wasigh]

g.FillRect ter grote van de applet in de kleur van de achtergrond

je kunt ook repaint() aanroepen dan wordt dat automatisch voor je gedaan

[Verwijderd]

Thanks! Ga het meteen proberen

[.oisyn]

een betere manier is natuurlijk om datzelfde vierkant eroverheen te tekenen met de achtergrondkleur, en vervolgens weer een vierkant met de voorgrondkleur tekenen op de volgende positie

[Verwijderd]

Als ik Fillrect() gebruik krijg ik een knippereffect, omdat het vierkant steeds heel eventjes verdwijnt. Dan de repaint() methode uitzoeken...weet iemand een goede link?

[.oisyn]

doe het nou eens op de manier die ik hierboven beschreef... dan zal je zien dat het al een stuk minder knippert

Maar nog beter is om met backbuffers te werken. Je maakt een offscreen image met de createImage (int width, int height) functie, waarin je vervolgens tekent

vervolgens teken je die image over je applet heen met g.drawImage ()

[Verwijderd]

http://javaboutique.internet.com/tutorials/Step/Chapter4/DoubleBuffering.html

[kvdveer]

Die link die ScitzoFreak post is een hele goeie. Probeer eens wat tutorials over animatie in java te zoeken. Een hoop dingen zijn al uitgevonden, en het kan je een hoop moeite schelen als je dat niet zelf opnieuw hoeft uit te vogelen.

deze pagina beschrijft een aantal basistechnieken. Ook double buffering staat beschreven.

[Verwijderd]

Thnx, ik graaf verder. Overigens, de eerste methode doe Oysin beschrijft geeft (natuurlijk) ook een knippereffect.
Nu het bufferverhaal achter die link van ScitzoFreak lezen...

ps. de code tot nu toe heb ik voor geïnteresseerden op internet gezet: http://www.odessa.nl/rubenski/screensaver.htm

[.oisyn]

maak er eens een .txt van ipv .htm, dan blijft de indentatie tenminste behouden

.edit: ik heb hier trouwens nog wat leuke applets staan

[Verwijderd]

http://www.odessa.nl/rubenski/screensaver1.txt

[kvdveer]

Mag ik schieten?

Je code ziet er goed uit... al vind ik varaiabelnamen a en b wat te vaag. Zeker voor class variabelen.

Doorgaans zet je een animatieapplet als volgt in elkaar:
(typo's voorbehouden)
(het is >1 jaar geleden dat ik iets met java heb gedaan)

code:

public class onzin extends Applet implements Runnable {
  Thread animator;
  Image offImage;
  Graphics offGraphics;   
  boolean terminated=false;

  public void start() {
    
    offImage = createImage(width, height);
    offGraphics = offImage.getGraphics();
    animator = new Thread(this);
    animator.start();
  }
  
  public void stop() {
    terminated=true;
  }

  public void paint(Graphics g) {
    synchronized(offImage) {
    g.drawImage(offImage, 0, 0, null);
    }
  }


  public void run() {
    while (!terminated) { 
    synchronized(offImage) {
      // leef je uit op offgraphics 
    }
    
    repaint();
    
    try {
      Thread.sleep(100); // wacht een poosje
    } catch (InterruptedException e) {
      break; // als iemand stoort de thread afbreken.
    }

    }
  }
}

Ik heb hier helaas geen compiler om het te testen...
Als je de bovenstaande code gebruikt heb je (naar ik verwacht) je eerste multithreaded applicatie geschreven.
Vraag gerust raak over de bovenstaande code.

edit:

void stop() toegevoegd.

[.oisyn]

eigenlijk moet je ook nog de stop methode implementeren zodat je de thread weer kan stoppen

[kvdveer]

Op zaterdag 29 december 2001 22:28 schreef OiSyN het volgende:
eigenlijk moet je ook nog de stop methode implementeren zodat je de thread weer kan stoppen

Die heb ik er in mijn edit bij gezet.
Echt heel nuttig is het niet. De browser roept alleen STOP aan bij het afsluiten van je applet. Dan wordt die thread vanzelf wel gestop hoor... Maar het is inderdaad netter.

[mbravenboer]

Eigenlijk moet de methode stop ook nog synchronized zijn. De toegang toe de variabele terminated moet ook synchronized zijn. Hier kan je dan beter even een aparte methode voor maken...

[kvdveer]

Op zaterdag 29 december 2001 22:35 schreef mbravenboer het volgende:
Eigenlijk moet de methode stop ook nog synchronized zijn. De toegang toe de variabele terminated moet ook synchronized zijn. Hier kan je dan beter even een aparte methode voor maken...

Start hoort idd ook synchronized te zijn .

Waarom moeten stop en terminated synchronized zijn? Er wordt door de thread main naar terminated geschreven en door de thread animator uit gelezen.
Het is dus niet mogelijk om perongeluk het 'werk' van een andere thread te overschrijven, en als animator een terminated nèt mist, dan ziet 'ie 'm 100 ms later wel weer.
Het kan natuurlijk dat ik het niet begrijp. Ik heb namelijk nog nooit serieus aan multithreading gedaan (wat trouwens in java echt het einde is, relatief tot andere talen).

[edit]
Start hoort zeker synchronized te zijn... Bovendien hoort er in update een check te zitten dat offimage en offgraphics echt niet null zijn.
Maar ja... het was maar een opzetje.

[mbravenboer]

kvdveer: Waarom moeten stop en terminated synchronized zijn? Er wordt door de thread main naar terminated geschreven en door de thread animator uit gelezen.

Precies, om de toegang tot de variabele terminated te beschermen moet deze altijd in een monitor worden aangepast. Het zal waarschijnlijk in dit geval wel goed gaan, maar het is nooit verstandig om 2 threads tegelijk aan 1 variabele te laten zitten. Zodra variabelen gebruikt worden door meerdere threads moeten ze beschermd worden.

Zie voor meer info o.a. dit:
http://java.sun.com/docs/books/tutorial/essential/threads/monitors.html

Het kan natuurlijk dat ik het niet begrijp. Ik heb namelijk nog nooit serieus aan multithreading gedaan (wat trouwens in java echt het einde is, relatief tot andere talen.

Op zich zal het hier niet fout gaan, maar het is toch een goede gewoonte om variabelen te beschermen tegen gebruik door meerdere threads . Variabelen mogen alleen aangepast of opgevraagd worden in een monitor (synchronized block dus) als ze gebruikt worden door verschillende threads.

Als je geinteresseerd bent in multi-threading kan ik je zeer sterk het uitstekende boek "Concurrent Programming in Java, Design Principles and Patterns" van Doug Lea aanraden .

[.oisyn]

kvdveer: Dan wordt die thread vanzelf wel gestop hoor...

Daar mag je dus niet van uit gaan