[Java] traag tekenen paintComponent

[Tjeerd]

Ik heb het volgende probleem, ik heb een groot plaatje van bijvoorbeeld 1000x1000 pixels in een BufferedImage. Vervolgens heb ik een soort van navigatiepaneel (rechtsboven) op m'n scherm waarmee ik over een verkleinde versie van dat hoofdplaatje beweeg met een selectie-vierkantje. Op mijn *hoofdscherm* zie je een vergroting van het geselecteerde stukje. Bezie dit allemaal als een soort van Dune2-achtige interface.



Dan nu de code die het doet (beetje pseudonamen gebruikt):

Java:

BufferedImage hoofdplaatje = new BufferedImage(1000,1000, BufferedImage.TYPE_INT_RGB);

public void paintComponent(Graphics g) {    
super.paintComponent(g);        
Graphics2D g2context = (Graphics2D)g;

BufferedImage subimage = hoofdplaatje.getSubimage(getAbsoluteX(), getAbsoluteY(), ovp.getBlocksize(), ovp.getBlocksize());

g2context.drawImage(subimage,0,0, getSize(), getSize(), this);

//getSize() is in dit geval de grootte van het grote vierkant in het plaatje hierboven

g2context.dispose();
}

Werkt op zich prima, alleen het gaat soepel zolang het hoofdplaatje ~ 400x400 pixels is. Ga ik met hoofdplaatjes werken groter dan ~ 400x400 pixels dan gaat de snelheid steeds meer naar beneden wanneer ik er overheen beweeg - je scrollt dan als het ware over de map heen, wederom net als in bijv. Dune.

Enkele dingen die ik tegen ben gekomen is VolatileImage-klasse, iets met clipping te doen e.d. Maar zoiets als een simpele getsubimage zou toch gewoon snel moeten zijn?

[ Voor 5% gewijzigd door Tjeerd op 30-08-2006 10:59 ]

[The Fox NL]

Misschien moet je deze call eens proberen.
Ik weet niet precies wat ie doet, maar ik denk zomaar dat je code dan zoiets wordt:

Java:

g2context.drawImage(subimage,0,0, getSize(), getSize(), getAbsoluteX(),
                    getAbsoluteY(), getAbsoluteX() + ovp.getBlocksize(), 
                    getAbsoluteY() + ovp.getBlocksize(), this); 

ipv.

Java:

BufferedImage subimage = hoofdplaatje.getSubimage(getAbsoluteX(), getAbsoluteY(), ovp.getBlocksize(), ovp.getBlocksize());

g2context.drawImage(subimage,0,0, getSize(), getSize(), this);

En misschien kan je je grote plaatje scrollbaar maken, maar laat je de scrollbars weg en scroll je aan de hand van je minimap?

[JKVA]

Ik zou toch eens serieus naar VolatileImage kijken, dat scheelt al stukken.

Daarnaast, als je maar een stukje tekent van je hoofdimage, waarom maak je er dan zo'n grote van? En per frame opnieuw? Ik zou persoonlijk ergens een 2d array ofzo bijhouden van je spelwereld, die in leven houden en alleen aanpassen als dat nodig is. En dan dus, je raadt het al, niet met een hoofdimage werken, maar alleen de image die je weergeeft en precies de pixels bevat die op het scherm komen.

Misschien kun je ook, maar ik weet niet of dat echt significant scheelt, je image in leven houden en alleen steeds de data overschrijven.

[Tjeerd]

Bedankt The FOX NL, die methode heb ik over het hoofd gezien. Wat ik nu in eerste instantie doe is een originele 'kaart' aanmaken die de heatmap bevat - het is niet voor een spel, maar eerder wetenschappelijke doeleinden, vandaar een heatmap. Deze heatmap gebruik ik als het ware als 'originele' template. Daarnaast heb ik een 'werk' heatmap, deze gebruik ik om de gebruiker echt op te laten knoeien/selecties maken. Ik houd bij die werk heatmap een 2d-boolean array bij van gebieden die geselecteerd zijn.

Wanneer een gebruiker nu een selectie maakt wordt in de 2d-array bijgehouden waar een selectie is gemaakt - de gebruiker kan tot op pixelniveau selecties maken en op allerlei plekken op de kaart, dus een 2d-boolean array leek me op zich het handigst. Als de gebruiker een selectie heeft gemaakt wordt op de werkheatmap het gebied een kleur gegeven (eigenlijk een XOR van het gebied). Dit werkt nu prima verder.

Dat VolatileImage ben ik zo snel even dit van tegengekomen. Ziet er op zich ook interessant uit. Ik zal moeten kijken of ik dat kan gebruiken en zoja, of het echt verschikkelijke winst oplevert.