Guarda, come esempio ti porto al mio programmino pgDesigner (puoi trovarlo su sf.net), che ho iniziato a sviluppare da ormai più di un anno, rivoluzionandolo ogni volta per cercare di trovare il modo più adatto per velocizzare il più possibile il disegno. Questo programma non è altro che una specie, se hai presente, di Erwin o Oracle designer, solo che è fatto per postgres.
Ora,
Per i punti, come hai scritto, in effetti data l'assenza di un qualche funzione che possa aiutarti a capire se un pixel è più o meno accesso, e magari di che colore, devi per forza farti una mappa personale in memoria (cosa che è abbastanza pesante). Il programma in questione disegna una certa quantità di recttangoli contenenti righe di testo, hai presente una tabella con il nome scritto in testata e l'elenco dei campi a seguito ? Una specie di piccola form insomma. Questi rettangoli, se definiti tabelle, posso essere collegati tramite linee, più o meno rette (dipendentemente dalle impostazioni utente), con a volte dei testi scritti.
Insomma, ogni oggetto si disegna da solo nell'area grafica, e un loop esegue l'operazione. Se questi oggetti raggiungono una certa quantità, il refresh dell'area diventa fastidioso, come se dovessi dipingere a mano un quadro... :-)
Ti ricordo che questi oggetti devono essere spostati tramite mouse, ritracciando le linee di relazione in modo costante, per cui l'immagine finale non è statica.
Se hai provato a disegnare pochi oggetti, questa cosa non si nota, o perlomeno si nota appena.
La scappatoia che ho trovato io? Disegno ogni oggetto su una picture (ridimensionabile a seconda del contenuto), e ogni oggetto è associato al contenitore che è poi l'area di disegno; le linee invece sono costretto a disegnarle nell'area direttamente. In questo modo il movimento degli oggetti viene gestito direttamente dal motore grafico, e io devo controllare solo che un elemento non esca dai margini.
Nelle ultime versioni ho aggiunto un'ulteriore oggetto, un'area rettangolare, più o meno colorata con testo incluso, ridimensionabile dall'utente tramite il mouse; purtroppo, per il suo scopo, quest'oggetto deve venir disegnato alla stregua delle linee, per il fatto che questo non deve mai coprire un oggetto tabella (ovviamente). Ancora una volta, purtroppo, mi sono scontrato con la lentezza delle librerie, e questa volta la causa è la dimensione di queste aree, oltre al loro movimento.
Tanto per la cronaca, l'area di disegno ha le dimensioni di 3x4 fogli in formato A4, più o meno 3000x2000.
La prova con cache=true l'ho fatta, ed è tuttora impostata, ed è stata obbligatoria, altrimenti ero ancora in attesa del refresh... :-)
Per il rilevamento dei punti, come ho già accennato, devi per forza tenere traccia del grafico, ma per fortuna io non ne ho necessità.
Sempre come ho scritto nel precedente msg, ho fatto prove con altri linguaggi e questa cosa non è avvenuta, nonostante si aggancino quasi tutti alle stesse librerie (qt o gtk). Python, ad esempio, ha un oggetto simile alla AreaDrawing, che ha la possibilità di sapere le caratteristiche di tutti gli oggetti grafici che hai disegnato (es. posizione, colore, ecc.); in java ho notato con stupore che la parte grafica è stata potenziata notevolmente, raggiungendo livelli quasi pari al C/C++.
Credo che Gambas dovrà faticare non poco per raggiungere questi livelli, ma io confido che al più presto sarà veramente un linguaggio completo, anche visti i notevoli progressi fatti in questo poco tempo di vita.
L'idea di sviluppare il mio progetto è stata proprio quella di scoprirne le funzionalità e la potenza, e devo dire che Gambas mi piace.
Spero possa essere in un prossimo futuro un'alternativa valida al basic di windoz.
Comunque, visto il tuo interessamento, se tu serve aiuto in qualche tuo progetto, oppure esperimento in genere, sono ben felice di darti una mano (sempre dipendentemente dal tempo a disposizione...).
Bye