Newsgroup: it.comp.java
Titolo: Sulle api 2d e il loro utilizzo...

Salve ragazzi,
magari qualcuno si ricorda ancora di me: non ho purtroppo (per me, non per
voi) tempo di frequentare continuativamente e costruttivamente questo NG,
però da bravo casinista imbranato ogni tanto mi affaccio a proporre problemi
strani. Questa volta tocca a....
Allora: sto cominciando ora a smanettare con la parte grafica di java (si
parli di swing, di awt di java 2d sono ignorante allo stesso modo: molto!),
e quindi mi scuso se sono impreciso e vi farò un po' confondere. Veniamo al
problema: mettiamo che io abbia un segnale (un elettrocardiogramma), cioè
una sequenza di valori, e che volgia disegnarlo. Per il momento ho pensato
e/o visto tre approcci al problema:
1) visto: si genera una bitmap "volatile" della dimensione della finestra,
ci si disegna sopra una linea che congiunge i punti (solo quelli che
ricadono nella visualizzazione in funzione delle scale scelte) e poi la si
disegna sulla finetra. se si deve fare lo scroll si rigenera la bitmap,
eventualemtne "riciclandone" la parte centrale (cioò si butta via quello che
esce dallo schermo, si copia quello che vi rimane anche se in posizione
diversa, e si riempie lo spazio "nuovo")
2) visto: si disegna direttamente sul componente che ospita la
visualizzaione (jpanel ad esempio) con "g.drawLine", scorrendo sui punti
dell'array (il segnale) che ricadono nell'intervallo di visualizzaizone. Se
si deve scrollare si ripete l'operazione cambiando i punti di inizio e di
fine
3) pensato: ispirato ai principi del disegno vettoriale, potrei costruire il
mio oggetto (GeneralPath?) completo, che sarebbe un'entità matematica
statica nelluser space. A questo punto, giocando sulle trasformazioni, sui
clipping path o su qualcos'altro (e questo va appurato), potrei disegnare di
volta in volta solo la parte che "cade" nella mia finestra, senza però
rigenerare l'oggetto tutte le volte
Vi chiedo (per il momento) due cose:
- quale di questi è secondo voi il metodo più corretto, e perchè? Tenete
conto che per me ha una certa rilevanza la velocità, mentre non ne ha ad
esempio lutilizzo di memoria...
- in riferimento all'ultimo metodo, qual'è il modo furbo di attuarlo? Io ho
notato che se gli chiedo semplicemnte di disegnare il mio oggetto in una
finsetra che non lo contine tutto, o magari con un clip path, lui lo disegna
comunque tutto e poi mi fa vedere solo la parte giusta, ma questo ovviamente
da problemi di prestazioni con oggetti molto complessi... non si può
limitare "realmente" (nel senso che lui proprio quelle operazioni non le fa)
la prozione di oggetto che lui sottopone a rendering?
Spero di aver presentato il problema in modo abbastanza comprensibile e vi
ringrazio da ora per la disponibilità, chiedendovi ovviamnete di sparare
pure ogni osservaizone/consiglio vi passi per la testa, anche non
direttametne legata alle mie domande.
Grazie
Giacomo

Giacomo Ciani wrote:
Ciao giacomo , ho letto velocemente quello che hai scitto e mi sono venute 
in mente un paio di cose ( ma son niubbo per cui prendile con le pinze).
Sfrutterei la clase javax.swing.Time per richiamare un metodo che mi disegni 
un segmento partendo dal punto finale del segmento precedente ( nel primo 
segmento parte da un origine che setterai tu nel costruttore) e che arriva 
al nuovo punto, una roba simile:
public void draw(Graphics2D g2, Point2D newPoint)
{
Line2D segment = new Line2D.Double(oldPoint, newPoint);
g2.draw(segment);
oldPoint = newPoint;
}
un bel listener per Time che richiami un metodo simile .
CON LE MOLLE !!  Ho tirato cosě e ho poco tempo : a casa provo a vedere se č 
fattibile.
-- 
Ciao. Fabrizio. ( icq: 241182067 )
< MISTAH KURTZ -- HE DEAD.
                A penny for the Old Guy> 
(T.S. Elliot: the hollow men)

Ti ringrazio per la risposta, ma il mio problema non è tanto generare il
tratto del segnale: so come fare e anzi ho due o tre alternative; il mio
problema è capire quale delle alternative presenta il miglior rapporto tra
facilità e comodità di implementazione e prestazioni di ridisegno...
Un esempio: lascaimo stare il tempo reale, e pensiamo di avere già tutto il
nostro elettrocardiogramma (arrai di valori interi). Una cosa comodissima e
veloce da fare è istanziare un generalpath e fare un ciclo che per ogni
punto del segnale faccia un "lineTo" al nuovo punto. Adesso settanto le
opportune "transformation" dell'oggetto grafico posso fargli disegnare a
schermo il mio general path con la scala che mi pare, e inserendolo in uno
scrollPane ho bell'e pronto il metodo per scrollarlo in lungo e in largo.
Ottimo, no? No! Perchè anche se nello scrollpane nè vedo solo un pezzo,
sembra che lui faccia l'operazione di ridisegno sull'intero oggetto: questo
vuol dire che se il segnale è fatto da migliaia di campioni, anche se
nell'area visibile ne ricadono solo pochi, l'operazione di ridisegno è
comunque lenta...
Questo per darti un'idea di qual'è il problema in gioco. Se poi ti va di
parlare nache delle altre soluzioni che ho considerato con realtivi
vantaggi/svantaggi, ci diamo a post lunghissimi...

 vantaggi/svantaggi, ci diamo a post lunghissimi...
con piacere.


e/o visto tre approcci al problema:
[CUT]
Magari non ti serve a niente, ma prova a guradare il demo Java2D nella 
cartella demo del tuo jdk: in particolare il codice del piccolo display 
"MemoryMonitor".
HTH
-- 
Ciao
	Fabrizio C.

 Tutto sommato hai già risolto ...
Si, ma pare che le API java per il 2d disegnino comunuqe tutto l'oggetto,
anche se poi se ne vede realmente solo un parte. Questo vuol dire che se
nella mia finestra entrano 1000 campioni di un segnale che fatto da un
totale di 5000, non ho problemi; se entrano invece sempre 1000 campioni, ma
di un segnale che ne ha in totale 1.000.000, allora l'oerazione di ridisegno
sarà lentissima...
In pratica gli approcci sono due: generare di volta in volta l'oggetto da
diseganre con i soli campioni che risultano visibili, o aver un oggetto
unico e "vederene" solo una parte. Il primo approccio è performante e non
presenta problemi, quindi va bene. Se però riuscissi a risolvere il problema
delle prestazioni, il secondo sarebbe molto più comodo dal punto di vista
dell'implementeazione e della gestione...
E qui sta il vero problema, che però a questo punto comincio a dubitare si
possa risolvere nei termini in cui pensavo io...
Ciao
Giaocmo