[Java]DoubleBuffering is oplossing voor flikkeren?

[Verwijderd]

We werken in Swing. We hebben een knop aangemaakt waarmee je kan resizen met behulp van mousemotionlistener en mouselistener.
Het probleem is nu dat de scherm begint te flikkeren tijdens het resizen. We hebben doublebuffering geprobeerd:
((JPanel)this.getContentPane()).setDoubleBuffered(true);
Dit is iets wat we op internet vonden, maar de JFrame flikkert nog steeds. We denken dat dit een algemeen probleem is, dus weet iemand hier een oplossing voor? We konden het niet zo op http://java.sun.com/ en andere site vinden. Alleen bovenstaande regel vonden we.

[drm]

Alleen bovenstaande regel vonden we.

[/nohtml]

offtopic:
Juist. Zou je dergelijke uitbarstingen van smileys even kunnen vervangen door een goede onderbouwing voortaan?

[Alarmnummer]

Post anders ff een stukje code zodat de rest kan zien wat het probleem nu precies is

[Verwijderd]

hmm dit is al het derde topic over vrijwel hetzelfde probleem. Over dubbel buffering in het algemeen en over swing is op got al genoeg te vinden...

[Verwijderd]

private class MouseMotionListenerImpl implements MouseMotionListener{
public void mouseDragged(MouseEvent e) {
Point point = e.getPoint();
int x = point.x;
int y = point.y;
setSize(breedte + (x-pressedX),lengte + (y-pressedY));
Graphics g = getGraphics();
update(g);
}

public void mouseMoved(MouseEvent e) {
}
}

Wij hadden in een eerdere post gehoord dat dubbelbuffering de oplossing was en dat we dat zelf maar moesten opzoeken.. Dat hebben we gedaan.. we vonden naar lang zoeken deze regel: ((JPanel)this.getContentPane()).setDoubleBuffered(true);
Het blijkt echter niet het probleem te verhelpen.. Iemand anders nog een idee? Wij hebben echt tijden gezocht en niks bruikbaars gevonden..

[Verwijderd]

Verwijderd schreef op 02 april 2003 @ 11:34:
hmm dit is al het derde topic over vrijwel hetzelfde probleem. Over dubbel buffering in het algemeen en over swing is op got al genoeg te vinden...

okee....Link aub als je het tenminste weet

[Verwijderd]

ik weet niet in welke context dit staat, maar ik gok binnen een JFrame, en volgens mij omzeil je nu de dubbele buffering door je update, maar dat weet ik niet zo 123 zeker.

[roelio]

code:

[code] tags even gebruiken?[/code]

[Krooswijk.com]

weet niet of het vb hieronder op swing van toepassing kan zijn, maar dit is iig hoe dubbele buffering normaal werkt:
http://developer.java.sun...terviews/DoubleBuffering/
bovenaan staat de link naar een tekstbestand met dubbele buffering voorbeeld

[Verwijderd]

Swing gebruikt automatisch al double buffering. Bij de awt packages moest je zelf een buffer (met een image enzo) maken. Die flikkering zou dan ergens anders moeten wegkomen, of is niet te verhelpen.

[Verwijderd]

Da Snake schreef op 02 April 2003 @ 11:41:
weet niet of het vb hieronder op swing van toepassing kan zijn, maar dit is iig hoe dubbele buffering normaal werkt:
http://developer.java.sun...terviews/DoubleBuffering/
bovenaan staat de link naar een tekstbestand met dubbele buffering voorbeeld

Ik kom er daarmee nog niet uit hoe je het bijvoorbeeld met een JFrame moet doen . Dit is een voorbeeld van double buffering van een Image, en niet van een JFrame. En als reply op een paar posts hierboven, de smilies zijn er toch voor om te gebruiken?

[Verwijderd]

Verwijderd schreef op 02 April 2003 @ 11:49:
Swing gebruikt automatisch al double buffering. Bij de awt packages moest je zelf een buffer (met een image enzo) maken. Die flikkering zou dan ergens anders moeten wegkomen, of is niet te verhelpen.

Heeft iemand hier nog een oplossing voor....Dus het ligt kennelijk niet aan double buffering.. het is wat anders. Heeft iemand een idee waar het dan aan kan liggen..dat het scherm zo flikkert als ik he JFrame vergroot met zelfgemaakt component.
Het lijkt me sterk dat het onmogelijk is... Me de standaard vergroot manier van een JFrame gaat het wel goed. (Naar de rand gaan van JFrame en naar binnen of naar buiten slepen)

[ Voor 15% gewijzigd door Verwijderd op 02-04-2003 11:56 ]

[Verwijderd]

Ook al dubbel buffer je 1 component, als de parent niet dubbel gebuffered is haalt het nog weinig uit. Kijk is goed naar wat je doet, dus hoe je programma verloop is. Probeer eerst te begrijpen hoe java werkt (niet lullig bedoeld).

[Verwijderd]

Verwijderd schreef op 02 april 2003 @ 12:00:
Ook al dubbel buffer je 1 component, als de parent niet dubbel gebuffered is haalt het nog weinig uit. Kijk is goed naar wat je doet, dus hoe je programma verloop is. Probeer eerst te begrijpen hoe java werkt (niet lullig bedoeld).

Maar vorige reactie zei dat het waarschijnlijk niet aan dubbel buffering lag dat Swing dat automatisch al deed. Gaat over een JFrame...dus is Swing... Moet dus ergens anders aan liggen

[Woy]

je moet eens goed kijken wat er nou precies flikkert. In het stukje code wat je post zie ik waarschijnlijk al een probleem. Het zal jouw probleem wel niet oplossen maar ik post het toch maar even.

Java:

Graphics g = getGraphics();
update(g);

Hoezo roep je hier zelf de update functie aan. Dit is niet echt de bedoeling. je moet gewoon de repaint functie aanroepen. Dan wordt er intern in java voor gezorgd dat de update en paint functies worden aangeroepen

[Verwijderd]

maar ik weet niet wat jou component doet, of die misschien wel het zaakje verpest. Je hebt immers met een kale swing applicatie (desnoods een button erop) nergens last van. Ik zou dus eerder zeggen dat je zelf iets over het hoofd ziet, in plaats van gelijk swing als de schuldige aan te wijzen :-) Dus daarom zeg ik kijk eerst is naar je programma verloop, ondermijn je de buffer niet ergens?

[Verwijderd]

Verwijderd schreef op 02 April 2003 @ 12:11:
maar ik weet niet wat jou component doet, of die misschien wel het zaakje verpest. Je hebt immers met een kale swing applicatie (desnoods een button erop) nergens last van. Ik zou dus eerder zeggen dat je zelf iets over het hoofd ziet, in plaats van gelijk swing als de schuldige aan te wijzen :-) Dus daarom zeg ik kijk eerst is naar je programma verloop, ondermijn je de buffer niet ergens?

Heb ik ergens Swing de schuld gegeven dan??.. Er stond in een eerder bericht dat Swing juist dubbel Buffering al heeft
Dus ligt het waarschijnlijk niet aan dubbelbuffering...
Het Component wat wij gemaakt hebben is een knop die reageerd aan de hand van mousepressed en mousedragged. Het scherm beweegt goed mee daar is niks mis mee... Hij flikkerd alleen als een gek...
Volgens mij flikkerd het JFrame niet echt maar de inhoud wat er op staat... Bij ons een JDesktoppane.


(Op reply daarvoor... repaint() geeft precies hetzelfde resultaat)

[ Voor 6% gewijzigd door Verwijderd op 02-04-2003 12:19 ]

[Woy]

repaint() geeft mischien wel wel hetzelfde eindresultaat maar de afhandeling is zeker wel anders.
En als je zelf een JDesktoppane hebt dan zul je dus moeten zorgen dat deze double gebuffered is. Als je hier zelf op aan het painten bent zou het bijvoorbeel hier aan kunnen liggen.

[Verwijderd]

rwb schreef op 02 April 2003 @ 12:30:
repaint() geeft mischien wel wel hetzelfde eindresultaat maar de afhandeling is zeker wel anders.
En als je zelf een JDesktoppane hebt dan zul je dus moeten zorgen dat deze double gebuffered is. Als je hier zelf op aan het painten bent zou het bijvoorbeel hier aan kunnen liggen.

We konden ook die repaint() weghalen... gaf ook nog hetzelfde resultaat.... als je resize aanroept wordt namelijk repaint() ook al uitgevoerd.

[Soultaker]

Kun je een volledig voorbeeldprogramma van 1 of 2 schermen code geven dat je probleem illustreert?

[Verwijderd]

Hoe werken de codetags precies? Dan zal ik de code hier posten

[ Voor 98% gewijzigd door Verwijderd op 02-04-2003 12:53 ]

[Verwijderd]

code:

package org.jph.swing.desktoppane;

import javax.swing.*;

import java.awt.*;
import java.awt.event.*;

public class TestFrame extends JFrame {
    private int pressedX = 0, pressedY = 0;
    private Dimension dim = this.getSize();
    private int breedte = 0;
    private int lengte = 0;
    private Container cont = new Container();
    private JTextArea ar = new JTextArea();
    
    private MaxDesktopPane _maxDesktopPane = new MaxDesktopPane();
    public TestFrame() {
        getContentPane().setLayout(new BorderLayout());
        
        getContentPane().add(_maxDesktopPane,BorderLayout.CENTER);
        _maxDesktopPane.createFrame(new JScrollPane(ar));
        _maxDesktopPane.createFrame(new JLabel("foobar"));
        
        JPanel statusBar = new JPanel(new FlowLayout(FlowLayout.RIGHT,2,2));
        JButton resizeButton = new JButton(new RibbelIcon());
        resizeButton.setPreferredSize(new Dimension(17,17));
        resizeButton.setBorderPainted(false);
        resizeButton.setFocusable(false);
        statusBar.add(resizeButton);
        resizeButton.addMouseListener(new MouseListenerImpl());
        resizeButton.addMouseMotionListener(new MouseMotionListenerImpl());
        getContentPane().add(statusBar,BorderLayout.SOUTH);
        ((JPanel)this.getContentPane()).setDoubleBuffered(true);
    }
    
    private class MouseListenerImpl extends MouseAdapter{
        public void mousePressed(MouseEvent e)  {
            Point point = e.getPoint();
            pressedX = point.x;
            pressedY = point.y;
            breedte  = TestFrame.this.getWidth();
            lengte   = TestFrame.this.getHeight();
        }
        
        public void mouseReleased(MouseEvent e)  {
            //TestFrame.this.getRootPane().revalidate();
            //TestFrame.this.getRootPane().repaint();
            Graphics g = getGraphics();
            TestFrame.this.paintAll(g);
        }
    }
    
    private class MouseMotionListenerImpl implements MouseMotionListener{
        public void mouseDragged(MouseEvent e) {
            //setCursor(Cursor.getPredefinedCursor(Cursor.NW_RESIZE_CURSOR));
            Point point = e.getPoint();
            int x = point.x;
            int y = point.y;
            setSize(breedte + (x-pressedX),lengte + (y-pressedY));
            //repaint();
        }
        
        public void mouseMoved(MouseEvent e) {
        }
    }
    
    public static void main(String[] args) {
        String lookAndFeel = UIManager.getSystemLookAndFeelClassName();
        try {
            UIManager.setLookAndFeel(lookAndFeel);
        }
        catch (Exception e) {
            throw new RuntimeException(e);
        }
        TestFrame t = new TestFrame();
        t.setSize(500,500);
        t.setVisible(true);
    }
}

[ Voor 3% gewijzigd door Verwijderd op 02-04-2003 13:00 ]

[wasigh]

codetags: zie de FAQ
http://gathering.tweakers.net/forum/faq

Dubbelbufferen wil zeggen: eerst alles tekenen op een offscreen image en daarna deze image in zijn geheel op de graphics zetten.

o ja GoT heeft ook een search: http://search.gathering.t...5D=&data%5Bsearch%5D=Zoek

[ Voor 8% gewijzigd door wasigh op 02-04-2003 12:58 ]

[wasigh]

je roept zelf de paint aan:

Java:

Graphics g = getGraphics();
TestFrame.this.paintAll(g);

Daar ligt een gedeelte van het probleem, je moet repaint() aanroepen.

[Verwijderd]

offtopic:
wat is het toch met underscores (zo heten die liggende streepjes toch) bij private members, ik zie wel meer proggers dat doen. ik vind het bij java not done, zeker met het oog op Beans

En wat is je component, je MaxDesktopPane?

[Verwijderd]

wasigh schreef op 02 April 2003 @ 13:01:
je roept zelf de paint aan:

Java:

Graphics g = getGraphics();
TestFrame.this.paintAll(g);

Daar ligt een gedeelte van het probleem, je moet repaint() aanroepen.

3de keer dat dit nu wordt aangekaart

[Verwijderd]

Neej daar ligt het niet aan want het flikkeren gaat ook al zow als je de muis nog niet hebt losgelaten....Daarvoor voert ie dit nog niet uit. onder het mousedraggen flikkerd het scherm als een gek

(Als je resize aanroept wordt repaint ook al aangeroepen (al eerder gezegd))

[ Voor 18% gewijzigd door Verwijderd op 02-04-2003 13:06 ]

[wasigh]

Verwijderd schreef op 02 April 2003 @ 13:05:
Neej daar ligt het niet aan want het flikkeren gaat ook al zow als je de muis nog niet hebt losgelaten....Daarvoor voert ie dit nog niet uit. onder het mousedraggen flikkerd het scherm als een gek

(Als je resize aanroept wordt repaint ook al aangeroepen (al eerder gezegd))

Tja je kunt ook tips negeren

[Verwijderd]

Snap je niet wat ik zeg of zow??? Ik negeer het niet!!!
Staat toch dat repaint al wordt uitgevoerd als resize wordt aangeroepen.(repaint wordt in de methode resize aangeroepen)
Graphics g = getGraphics();
TestFrame.this.paintAll(g);
dit wordt pas aangeroepen als je muis loslaat.. dat is pas na het flikkeren van het scherm

[ Voor 8% gewijzigd door Verwijderd op 02-04-2003 13:13 ]

[wasigh]

Verwijderd schreef op 02 april 2003 @ 13:03:
wat is het toch met underscores (zo heten die liggende streepjes toch) bij private members, ik zie wel meer proggers dat doen. ik vind het bij java not done, zeker met het oog op Beans

Standaard is gezet door Gamme et al (desgin patterns)

En wat is je component, je MaxDesktopPane?

Dat vroeg ik me ook af ik kan hem niet compilen nu..

[drm]

Jongens, houd het een beetje rustig hier, ajb. Als we gaan lopen schreeuwen tegen elkaar heeft niemand er wat aan...

[Verwijderd]

wasigh schreef op 02 april 2003 @ 13:13:
[...]
Standaard is gezet door Gamme et al (desgin patterns)

offtopic:
Nog steeds vind ik het voor java not done, zeker een onderscheidt tussen private en public membersmag je zowat niet amken, aangezien je amper gebruik maakt van public members

[...]
Dat vroeg ik me ook af ik kan hem niet compilen nu..

Oftewel, we willen je component, daar waar het waarschijnlijk allemaal om draait

[Verwijderd]

Moet je de gehele code hebben?.... MaxDesktopPane == ook een appart bestand... De code die we gegeven hebben daar gebeurd het daadwerkelijke toch?

[Verwijderd]

ja maar wij willen graag compilen, geen zin om alles door te spitten...
edit:
plus dat de kans aanwezig is dat de fout daar zit...

[ Voor 31% gewijzigd door Verwijderd op 02-04-2003 13:21 ]

[Verwijderd]

Wil je dan misschien je mailadres hier neer zetten, zodat we je het kunnen opsturen. We kunnen het beter hier niet neerzetten, omdat het 5 java-bestanden groot is.

[Verwijderd]

[e-mail]

[Verwijderd]

Als het goed is heb je het nu binnen. We horen wel van je hier als er problemen zijn

[mbravenboer]

markvleth: Nog steeds vind ik het voor java not done, zeker een onderscheidt tussen private en public membersmag je zowat niet amken, aangezien je amper gebruik maakt van public members

Het onderscheidt ook juist instantie variabelen van lokale variabelen en methode parameters. Dat onderscheid is zeer nuttig.

Hetzelfde effect bereik je door overal "this." voor te zetten. Aangezien publieke members zoals je zelf al aangeeft "niet bestaan" heb je dus nooit publieke members met een _ . Publieke variabelen zijn constanten , en die schrijven we weer met hoofdletters.

[Soultaker]

Soultaker schreef op 02 April 2003 @ 12:44:
Kun je een volledig voorbeeldprogramma van 1 of 2 schermen code geven dat je probleem illustreert?

Ik wordt hier een beetje moe van. Je hoeft die code niet te geven, maar dan heb ik in ieder geval geen zin meer om je verder te helpen.

[Verwijderd]

Soultaker schreef op 02 April 2003 @ 14:01:
[...]

Ik wordt hier een beetje moe van. Je hoeft die code niet te geven, maar dan heb ik in ieder geval geen zin meer om je verder te helpen.

zoals we al eerder zeiden: Wil je dan misschien je mailadres hier neer zetten, zodat we je het kunnen opsturen. We kunnen het beter hier niet neerzetten, omdat het 5 java-bestanden groot is.

[Soultaker]

Verwijderd schreef op 02 april 2003 @ 14:03:
zoals we al eerder zeiden: Wil je dan misschien je mailadres hier neer zetten, zodat we je het kunnen opsturen. We kunnen het beter hier niet neerzetten, omdat het 5 java-bestanden groot is.

En zoals ik tot tweemaal toe al eerder zei: "Kun je een volledig voorbeeldprogramma van 1 of 2 schermen code geven dat je probleem illustreert?". Jij hebt gewoon geen zin je code te reduceren tot een formaat waar wij iets mee kunnen, zonder 'm helemaal uit te moeten pluizen. Als jij die moeite niet wil doen, wil ik geen moeite doen om jou met je probleem te helpen.

Het lijkt me sterk dat jouw probleem niet met een enkele testklasse te illustreren is. Als het met een 'klein' voorbeeld niet optreedt en met een 'groot' wel zul je zelf aan het debuggen moeten slaan, want dan doe je in je 'grote' case iets anders dan in de 'kleine'. Dat gaan wij niet voor jouw uitzoeken (kom nou!).

Het idee van GoT is dat iedereen er wat mee opschiet, als hier een probleem wordt omschreven en opgelost. Het is dus van belang dat hier het probleem duidelijk omschreven wordt en hier een oplossing wordt gegeven. Als jij mij gaat mailen moet ik zelf uitzoeken wat het probleem is en dan heeft verder niemand er wat aan (behalve jij) en dan kan ik je net zo goed persoonlijk terugmailen. Wat is dan nog het nut van GoT?

Ik wil je best persoonlijke support gaan geven maar dan moet dan wel een geldelijke vergoeding tegenover staan. Dat was vast je bedoeling niet. Als je gratis van mijn expertise gebruik wilt maken, dan gebeurt dat in een context waar anderen misschien ook nog eens wat aan hebben, en pas nadat je zelf de moeite hebt genomen het probleem zo te presenteren dat ik me alleen op de essentie ervan hoef te concentreren.

[ Voor 10% gewijzigd door Soultaker op 02-04-2003 14:20 ]

[Verwijderd]

ik heb geen problemen met je code (wel de twee assert's even wegge-comment), maar hij flikerd niet. Ik test het overigens op een p4 2.0, dus ik heb ook niet echt snel last van flikkering.

----------------
mbravenboer, alleen voor java blijft het not done, het gaat tegen de specificatie van beans in. this lijkt me duidelijk genoeg overigens...

[mbravenboer]

Verwijderd schreef op 02 April 2003 @ 14:18:mbravenboer, alleen voor java blijft het not done, het gaat tegen de specificatie van beans in. this lijkt me duidelijk genoeg overigens...

this. is alleen 4 tekens, _ is 1 teken .

Overigens zegt de Java Beans specificatie volgens mij niks over hoe je instantie variabelen moet noemen. Java Beans properties zijn toegankelijk via accessor methods en wat daar moet gebeuren is niet vastgelegd. Het kan direct een veld opleveren met dezelfde naam, een _veld of wellicht zelfs indirect een waarde opleveren.

[Verwijderd]

private int value, wordt
getValue
setValue

private int _value, wordt
get_value
set_value

Sommige tools herkennen het anders niet in hun object inspector...

[mbravenboer]

Dat is dan een probleem van die tools en (AFAIK) niet direct een conflict met de Java Beans specificatie ...

[Verwijderd]

mbravenboer schreef op 02 april 2003 @ 14:30:
Dat is dan een probleem van die tools en (AFAIK) niet direct een conflict met de Java Beans specificatie ...

Toch wel:
http://developer.java.sun...ns/Beans2/properties.html

[drm]

markvleth:
Toch wel:
http://developer.java.sun...ns/Beans2/properties.html

Stukje code van die pagina

Java:

    public Color getColor() {
        return beanColor;
    }

    public void setColor(Color newColor) {
        beanColor = newColor;
        repaint();
    }

Wat weerhoudt je er van 'bean' te vervangen door '_'

[Verwijderd]

hmm inderdaad, zover was ik niet gekomen, ik heb alleen dit gelezen

getPROPERTY
setPROPERTY

Nou dan hebben jullie gelijk, jammer genoeg, want dat streepje staat alleen al oerlelijk. Dus dat is dan tevens mijn pleidooi, het staat oerlelijk.

Of is dit er weer eentje van het type dat de java tuturials er naast zitten (net zoals bij session beans met het winkelmandje voorbeeld wat absoluut not done is)

[Verwijderd]

Verwijderd schreef op 02 April 2003 @ 14:56:
hmm inderdaad, zover was ik niet gekomen, ik heb alleen dit gelezen

[...]

Nou dan hebben jullie gelijk, jammer genoeg, want dat streepje staat alleen al oerlelijk. Dus dat is dan tevens mijn pleidooi, het staat oerlelijk.

Of is dit er weer eentje van het type dat de java tuturials er naast zitten (net zoals bij session beans met het winkelmandje voorbeeld wat absoluut not done is)

edit:
ik wist toch zeker dat ik het gelzen had, dus maar is de officiele specificatie in:
http://java.sun.com/products/javabeans/docs/beans.101.pdf
In in hoofdstuk 8 bij introspection staat inderdaad de manier zoals ik hem heb beschreven...

echte edit: oeps dat was dus niet de edit knop

[ Voor 4% gewijzigd door Verwijderd op 02-04-2003 15:08 ]

[Verwijderd]

Soultaker schreef op 02 April 2003 @ 14:18:
[...]


En zoals ik tot tweemaal toe al eerder zei: "Kun je een volledig voorbeeldprogramma van 1 of 2 schermen code geven dat je probleem illustreert?". Jij hebt gewoon geen zin je code te reduceren tot een formaat waar wij iets mee kunnen, zonder 'm helemaal uit te moeten pluizen. Als jij die moeite niet wil doen, wil ik geen moeite doen om jou met je probleem te helpen.

Het lijkt me sterk dat jouw probleem niet met een enkele testklasse te illustreren is. Als het met een 'klein' voorbeeld niet optreedt en met een 'groot' wel zul je zelf aan het debuggen moeten slaan, want dan doe je in je 'grote' case iets anders dan in de 'kleine'. Dat gaan wij niet voor jouw uitzoeken (kom nou!).

Het idee van GoT is dat iedereen er wat mee opschiet, als hier een probleem wordt omschreven en opgelost. Het is dus van belang dat hier het probleem duidelijk omschreven wordt en hier een oplossing wordt gegeven. Als jij mij gaat mailen moet ik zelf uitzoeken wat het probleem is en dan heeft verder niemand er wat aan (behalve jij) en dan kan ik je net zo goed persoonlijk terugmailen. Wat is dan nog het nut van GoT?

Ik wil je best persoonlijke support gaan geven maar dan moet dan wel een geldelijke vergoeding tegenover staan. Dat was vast je bedoeling niet. Als je gratis van mijn expertise gebruik wilt maken, dan gebeurt dat in een context waar anderen misschien ook nog eens wat aan hebben, en pas nadat je zelf de moeite hebt genomen het probleem zo te presenteren dat ik me alleen op de essentie ervan hoef te concentreren.

ik krijg zelf een berichtje terug van: 'Ik wil hem compilen, de code werkt niet er mist iets', dus daarom vragen we om het mailadres.

[mbravenboer]

markvleth: In in hoofdstuk 8 bij introspection staat inderdaad de manier zoals ik hem heb beschreven...

Het gaat er echter om dat er een verschil is tussen properties en variabelen. Variabelen zijn geen properties. Als je een get/set hebt definieert dit een property van de klasse en zegt het niets over de variabele. Dit is ook juist het centrale punt van Java Beans: het abstractie niveau moet juist nog verder omhoog en je wilt je dus helemaal niet bezighouden met de implementatie van een property. Een property heeft zelfs geeneens te corresponderen met een variabele (laat staan met de naam van die variabele).

[Verwijderd]

Wat een gezwam hiero Laten we eens proberen de topicstarter zijn probleem op te lossen.

Ik heb een renderer voor bepaalde figuren gemaakt. Ik extend JLabel. Om performance redenen etc.. overwrite ik wat methods. Probeer dat eens misschien heb je er wat aan.

Delen van mijn source:

Java:

public class TaskRenderer extends JLabel
                          implements CellViewRenderer, Serializable {

//KNIP

public Component getRendererComponent(//knip) {

    // Graph en enkele eigenschappen opslaan
    this.graph = graph;
    isDoubleBuffered = graph.isDoubleBuffered();

// Graph is een extended JComponent. Ik neem de waarde van DoubleBufferd van dit 
// object over. Aangezien de renderer op dit object wordt getekend. Ze zijn dus beide 
// true of beide false.

//KNIP

}

//KNIP

// Vanwege performance:

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void validate() {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void revalidate() {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void repaint(long tm, int x, int y, int width, int height) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void repaint(Rectangle r) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  protected void firePropertyChange(
          String propertyName,
          Object oldValue,
          Object newValue) {

    // Strings get interned...
    if (propertyName == "text")
      super.firePropertyChange(propertyName, oldValue, newValue);
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          byte oldValue,
          byte newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          char oldValue,
          char newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          short oldValue,
          short newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          int oldValue,
          int newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          long oldValue,
          long newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          float oldValue,
          float newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          double oldValue,
          double newValue) {
  }

  /**
   * Overridden for performance reasons.
   * See the <a href="#override">Implementation Note</a>
   * for more information.
   */
  public void firePropertyChange(
          String propertyName,
          boolean oldValue,
          boolean newValue) {
  }

Probeer dit eens uit en reageer op MIJN post of het gelukt is. Dan hoef ik tenminste niet het hele topic af te zoeken