Gambas-it
Archivi (sola lettura) => Domande tecniche (Gambas 2) => Topic aperto da: md9327 - 18 Settembre 2010, 15:59:59
-
Dato che allo stato attuale, con Gambas2, non sono riuscito a trovare sistemi per velocizzare il disegno su una DrawingArea, pongo questo quesito, nell'eventualità che qualcuno abbia qualche idea a cui non ho pensato...
Il problema è il seguente:
sò che ormai parlo solo di pgDesigner, ma è proprio su questo che stò lavorando per poter ottimizzare il disegno dei diagrammi.
In pratica ho un pannello, una DrawingArea, di dimensioni variabili, e comunque non inferiori a 500x500 pixel (può arrivare a dimensioni ragguardevoli, es. 16000x16000, su cui vengono disegnati diversi oggetti, il cui contenuto varia a seconda di alcune impostazioni.
Dalle prove che ho fatto, i tempi di elaborazione e disegno di questi oggetti, anche se di numero ragguardevole, sono calcolabili in millisecondi, per cui apprezzabili. Il problema nasce dalla necessità di implementare un sistema di zooming, in modo che il diagramma venga ridimensionato, ivi gli oggetti che contiene, rispetto ad una impostazione, che può variare dal 25% fino al 400%.
Onde evitare di ridimensionare l'area se non viene modificata rispetto alle dimensioni originali (100%), effettuo una semplice copia dell'immagine che, tra le altre cose tengo bufferizzata in un'oggetto Picture in memoria. Questa copia è praticamente indolore, nel senso che, nonostante le dimensioni del diagramma, è all'ordine anch'essa di pochi millisecondi.
Il problema si presenta, quando la procedura si accorge che c'è da effettuare un stretching, ovvero un ridimensionamento dell'immagine, rispetto alle impostazioni di base, ovvero se viene richiesto di ridurle o aumentarle secondo una determinata percentuale. In questo caso sono stato obbligato ad usare il metodo Stretch dell'oggetto Image, passandogli i giusti parametri di altezza e larghezza.
Dai test che ho effettuato, dopo aver ottimizzato tutto il codice che la procedura utilizza per il disegno, sono arrivato al punto in cui oltre non posso andare, ovvero devo usare una funzione (Stretch) di cui non sò assolutamente nulla.
I test, dicevo, mi hanno dimostrato che i tempi che alle funzioni, in particolare Image.Copy() e Image.Stretch(), occorrenti per completare il processo, sono tangibili, nell'ordine di secondi o decine di secondi, il che vuol dire che l'utente che guarda il diagramma, deve attendere molto prima di vederne i risultati, e devo dire che a me che l'ho costruito dà molto fastidio.
Tanto per fornire alcuni numeri, di seguito il debug di ogni singola operazione, tenendo presente che l'esempio di seguito mostrato si riferisce ad una elaborazione di stretching al 400%, con un diagramma finale di dimensioni pari a 12736x13476 pixel (un bel numero...):
Dimensioni finali DrawingArea: 12736,13476
Percentuale di zoom applicata: 400%
Disegno di tutti gli oggetti: Start: [09/18/2010 15:15:24.679] Tempo (secondi):
Semplice copia dell'immagine bufferizzata: Start: [09/18/2010 15:15:24.680] Tempo (secondi):
Stretching dell'immagine: Start: [09/18/2010 15:15:24.680] Tempo (secondi): [12]
Disegno del buffer sulla DrawingArea: Start: [09/18/2010 15:15:37.353] Tempo (secondi): [7]
Come si può notare, le uniche funzioni che hanno un tempo apprezzabile, sono relative allo strething e alla copia dell'immagine.
Devo anche dire che la cosa è proporzionale, ovvero al 200% i tempi diminuiscono della metà, e così via...
Con fattori di zoom inferiori al 100%, i tempi sono uguali a zero.
Come ho scritto, ogni singola riga del log si riferisce ad una determinata funzione dell'oggetto Picture (o Image), ovver il metodo chiamato, senza ulteriori codifiche inframmentate.
Come ultimo, faccio anche notare che il tutto ha girato sul mio pc, che ha una sk madre Asus, processore Intel QuadCore 2.5MHz, 8Gb di ram 800MHz, sk video NVidia Geforce 9300... e ho detto tutto... :rolleyes:
Sò che qualcuno del forum ha avuto modo di giocare con la grafica in Gambas, e forse può darmi un suggerimento su modi migliori, o alternativi, per poter velocizzare il tutto...
-
La butto lì.....hai provato ad estraniare lo zoom dal form in cui la drawing area si trova....magari gambas ridisegna tutto il form e questo porta via un po' di tempo....
prova a creare un form esterno in cui visualizzare lo zoom.....
Perchè ti dico questo? pensavo: il visualizzatore di immagini dei sistemi operativi ingrandisce le immagini impiegando pochissimo tempo....questo perchè in fin dei conti la finestra è semplice...magari riesci a guadagnare qualche secondo così.....
Oppure dovresti inglobare un visualizzatore di immagini già esistente nel tuo progetto...quando qualcuno vuole fare lo zoom tu salvi l'immagine e la passi al visualizzatore che si occupa di zoomarla per te....
Le mie sono solo stupide supposizioni poichè non mi sono mai trovato nella tua situazione...
-
visto che disegni in un a picture in memoria, hai provato a vedere se una picture box impiega meno tempo a caricare l' immagine del buffer?
per lo strect non saprei... non capisco perchè fai uno strech .. non puoi ridisegnarlo ingrandito?
-
[per Cesko]
Il disegno non interessa la form, e la drawingarea è incastonata in una serie di contenitori. Ad ogni modo, l'aggiornamento viene pilotato solo sulla drawingarea, e il refresh della form non viene interessato.
Tieni conto che i dati che ho pubblicato, sono il risultato di analisi all'interno della funzione stessa, per cui non viene fatto altro oltre a quello che ho analizzato.
Il visualizzatore di immagini cosa c'entra? Se parli di uno dei programmi che di solito è fornita una distro, il discorso non centra, perchè riguarda Gambas, e le sue librerie grafiche. Ovviamente gli altri programmi sono stati creati con altri linguaggi, magari più a basso livello. Comunque, tutto ciò non entra in merito... :-\
[per fsurfing]
Nessuna differenza con le picturebox, perchè non ha senso usare una picturebox di quelle dimensioni, e se poi non la usi per il suo scopo.
Nella prima stesura di pgDesigner, avevo utilizzato le picturebox per creare gli oggetti, questo per poter facilmente interagire con essi, muovendoli nel diagramma. Dato che, poi, analizzando e provando, ho notato che le differenze di velocità, gestibilità, e congruità rispetto al disegnare gli elementi direttamente sul diagramma, non erano apprezzabili e, oltretutto mi semplificava di molto agire direttamente sul diagramma, ho abbandonato la cosa nella versione 2.x.
Come da prospetto, il problema si pone solo con l'uso di particolari metodi di gambas, a cui non posso porre rimedio, se non andare a modificare il codice sorgente (in C). Il disegno di tutti gli oggetti, tenendo presente che questi possono cambiare interattivamente, ovvero spostati e ridimensioni tramite il mouse da parte dell'utente, non ha praticamente ritardi apprezzabili. Il problema si pone sulla copia tra l'immagine in memoria e la drawingarea, in particolare se si applica una trasformazione (appunto lo stretching).
Io posso anche capire lo stretch, a cui occorre un serie di algoritmi per poter traformare i pixel del disegno in modo da adattarli alle dimensioni volute, ma sulla copia non lo capisco. La velocità con cui dovrebbero essere copiati i pixel non dovrebbe essere visibile, addirittura 7 secondi!
Immaginate un DM come kde, o gnome, che ci mette ogni volta sette secondi per processare i pixel dello schermo. Dopo un paio di minuti, prenderesti una mazza, e distruggi il monitor... :hatecomputer:
Infine, è anche probabile che la funzioni di zoom a cui ho pensato, possa essere in qualche modo poco ottimale, ma sono obbligato a farla, dato che gli oggetti devono comunque poter essere manipolati tramite il mouse, ovvero trascinati, ridimensionati, ecc. In più, ogni qualvolta l'utente interviene, cambiando una impostazione di progetto, o una particolare proprietà del singolo oggetto, questo deve essere ricalcolato e ridisegnato, per poter immediatamente vedere la nuova struttura.
Pensandoci bene, in effetti questo mio dilemma me lo porto appresso dall'inizio del progetto, e sò anche benissimo che si tratta di uno dei limiti di gambas2, che spero abbiano in qualche modo migliorato con la versione 3.
Un pò di tempo fà, a seguito di queste considerazioni, avevo provato a riportare il progetto pgDesigner in Python e Java, e devo dire che le cose cambiano totalmente. La velocità delle funzioni di disegno sono impressionanti rispetto a gambas, oltre al fatto che hanno caratteristiche molto potenti, come ad esempio la gestione dei layer.
Vabbè, ho passato questo week, pensando e ripensando alla cosa, e non ne sono venuto fuori. Vorrà dire che dovrò mettermi sotto a provare Gambas3, per vedere se migliora qualcosa. Una pulce me l'ha messa Milio in un'altra discussione, e spero che si riscontri vera.
Grazie comunque per i tentativi che ho molto apprezzato, ma rimango comunque aperto ad eventuali altre idee, e il thread lo lascio open! :ok:
-
molto starno però! ho fatto delle prove e una picture di 13000X13000 mi viene disegnata sulla drawing in 4.2 e-5 secondi
logicamente lo stretch impiega del tempo...
ma perchè quando fai zoom invece di ingrandire l' immagine non la ridisegni direttamente impostando alle dimensioni di ogni oggetto lo zoom?
-
G2 è sempre stato "debole" nella gestione della potenza grafica e la riprova è la creazione di una specifica libreria in G3.
Per ovviare alla lentezza si possono usare vari artifici:
non visualizzare in tempo reale il disegno
disegnarlo su una zona invisibile e successivamente ricopiarlo (caricandolo proprio come immagine e non come copia da drawing a drawing)
creare dei falsi zoom (tipo solo il contorno dell'oggetto)
Ovviamente tutto questo non va certamente a vantaggio della qualità del progetto.
-
molto starno però! ho fatto delle prove e una picture di 13000X13000 mi viene disegnata sulla drawing in 4.2 e-5 secondi
logicamente lo stretch impiega del tempo...
Infatti, la copia della picture impiega 5 secondi. il fatto che a me ne segna 7 può dipendere da altri fattori, e non è detto che siano legati proprio a gambas. Tieni conto che il sistema ha comunque in piedi dei servizi (molti) ed è a 64bit, per cui in alcune parti sembra più lento ad elaborare.
Comunque la tua prova è il riscontro delle mie...
ma perchè quando fai zoom invece di ingrandire l' immagine non la ridisegni direttamente impostando alle dimensioni di ogni oggetto lo zoom?
Prova già fatta e scartata subito, per il fatto che complica notevolmente la gestione. L'idea sarebbe buona, ma il numero e le tipologie di oggetto disegnabili sono abbastanza, e già ci sono un certo numero di parametri che transitano tra le varie funzioni. La cosa che ho notato manca alla gestione degli oggetti (o classi) è il fatto di poter definire una stessa funzione con diversi parametri, e l'interprete chiama quella corretta in base a come viene chiamata, un pò come funziona in C/Java. Questo mi ha obbligato a creare e duplicare alcuni oggetti, rendendo un pò arzigogolata la gestione.
G2 è sempre stato "debole" nella gestione della potenza grafica e la riprova è la creazione di una specifica libreria in G3.
Per ovviare alla lentezza si possono usare vari artifici:
non visualizzare in tempo reale il disegno
disegnarlo su una zona invisibile e successivamente ricopiarlo (caricandolo proprio come immagine e non come copia da drawing a drawing)
creare dei falsi zoom (tipo solo il contorno dell'oggetto)
Ovviamente tutto questo non va certamente a vantaggio della qualità del progetto
Infatti pixel, questo è stato ribadito più volte e in diverse occasioni, specialmente da me medesimo.
Riguardo agli artifici, ne ho implementati parecchi, oltre al sistema di caching (doppia immagine memoria->drawing) usata nel progetto.
Nonostante questo, che comunque ha notevolmente aumentato la velocità rispetto le prime versioni, mi trovo ora al punto di stop. Oltre le funzioni base di Gambas non posso, e non volglio, andare.
creare dei falsi zoom (tipo solo il contorno dell'oggetto)
Questo non posso farlo, perchè il dettaglio deve essere sempre visibile, oltre al fatto che l'oggetto deve essere interattivamente gestibile.
-
creare dei falsi zoom (tipo solo il contorno dell'oggetto)
Questo non posso farlo, perchè il dettaglio deve essere sempre visibile, oltre al fatto che l'oggetto deve essere interattivamente gestibile.
Ah.. non ho mai usato Pgdesigner e quindi non ho idea di che succede quando esegui lo zoom ;D
-
Ma come !?!?!? Mai usato pgDesigner? E non ti vergogni manco un pochino ? >:( :evil:
:P :P :P :bad: :bad: :bad: :rotfl: :rotfl: :rotfl:
-
mi sono espresso male, intendevo dire che a riempire la drawing con una picture mi impiega 4,2 esponente -5 secondi ovvero nulla, mi pare strano che a te ne impiegi 5 secondi
-
Ha, allora dimmi a livello di codice cosa hai fatto.
-
bho niente di che..
-
Perdona, ma come fà a funzionarti? A me blocca tutto...
Il disegno di quei cerchi l'ho ridotto a 5, ma ad ogni modo c'è qualcosa che non và.
E' pur vero che lo stò provando con il mio portatile in virtuale, ma non capisco perchè si inchioda...
-
Credo di aver trovato il problema fondamentale... la gestione della memoria....
Stò facendo girare su una macchina virtuale (con 1G di ram) il tuo programmino di esempio e, nonostante abbia limitato i loop di creazione, ci ha messo 5 minuti prima di dare un risultato ma, stranamente, ma come hai affermato, tutto a zero.
Questo non è proprio possibile, a meno che non subentri il discorso memoria. E' probabile, e dico probabile, che la gestione della memoria abbia un aspetto fondamentale nella velocità di esecuzione. Quello che è strano è che il mio sistema a casa ha ben 8Gbyte di ram, quindi dovrebbe sciacquare dentro come una rana nel lago di Como... ;D
Questa anomalia si riscontra anche nel timer che, a quanto pare inizia a contare quando in effetti la memoria termina di essere riempita.
Dopo i 5 minuti, il controllo ritorna e, sia i timer che le elaborazioni grafiche, iniziano ad essere processate.
Di certo è che le dimensioni della drawing sono ragguardevoli, se parliamo in puri pixel, escludendo l'oggetto in sè, abbiamo un numero totale di 169 miglioni di pixel, che rapportati in byte (da 8) sono oltre 20 MByte... Cavolo!!! Non avevo considerato questa cosa... anche se, in ogni caso, non giustifica i tempi...
-
Di certo è che le dimensioni della drawing sono ragguardevoli, se parliamo in puri pixel, escludendo l'oggetto in sè, abbiamo un numero totale di 169 miglioni di pixel....
Poi dite a me... ;D
-
:rotfl: :rotfl: :rotfl:
E vabbè, le vai proprio a cercare!
A parte gli scherzi, oltre al fatto che sono un dislessico, lo sai quale problema ho trovato con l'editor? Con IExplore non mi scrolla, per cui scrivo a memoria... 8)
Purtroppo qui sul lavoro devo usare il browser della ms... COn Firefox non lo fà...
-
Ho perseverato con i test, e dovuto anche stravolgere abbastanza il motore grafico di pgDesigner, provando il suggerimento di fsurfing che, in effetti avevo scartato a causa proprio dell'eccessivo lavoro da fare sul codice ma, alla fine l'ho fatto.
Devo necessariamente ringraziare "fsurfing", per avermi rispinto involontariamente sulla strada che avevo abbandonato.
In pratica ho dovuto modificare quasi tutte le funzioni grafiche del progetto, passando i parametri aggiuntivi e necessari per disegnare gli oggetti sul diagramma (vedi zoom ad esempio). Il disegno del grafico in precedenza era eseguito facendo lo streching di un'immagine in memoria popolata con gli oggetti. Per questa operazione, viste le dimensione del grafico, occorreva un tempo molto lungo, circa 20 secondi, molto fastidiosi da attendere...
Con l'inserimento delle nuove modifiche, ho eliminato la semplice funzione di streching, optando per il ridisegno completo di tutti gli oggetti del diagramma, opportunamente condizionato dalle impostazioni di zoom correnti.
Come risultato di tutto ciò, i tempi si sono accorciati a 2/3 secondi, dovuti al fatto che, comunque, lo strecthing viene applicati ad ogni singolo oggetto (ma le dimensioni sono molto piccole).
Ora stò provando ad eliminare anche lo streching sul singolo oggetto, forzando il disegno completo e, probabilmente abbassrò il tempo di attesa a meno di 1 secondo.
Farò sapere i risultati.
Grazie
-
ma quindi disegni direttamente sulla drawingarea oppure in una picture e poi la stampi nella drawing?
-
Dato che il programma si basa anche su un file di configurazione, questo contiene anche un setting per optare per:
a) disegnare direttamente sulla drawing
b) passare attraverso un'immagine in memoria a mò di cache
La b) è la migliore, perchè evita un piccolo, ma visibile e antipatico flash. Le ho provate entrambe e funzionano, ma la b) è quella di default.
Forse ti domanderai perchè lascio questa impostazione a mò di opzione... boh?!? ;D
In effetti cerco di parametrizzare tutto, il che mi lascia più margine per le modifiche.
L'unica cosa che mi piacerebbe fare, è la possibilità di poter far variare all'utente l'aspetto degli oggetti. Ad esempio, per le tabelle (stiamo parlando di tabelle di database), la forma è un rettangolo, con un'area superiore dedicata al nome dell'oggetto (parametrizzata come colore, font, icona, ecc.), e sotto l'elenco dei campi (parametrizzato in modo da poter sscegliere se visualizzare il solo nome con l'icona, il tipo, le dimensioni del campo, ecc.). La forma è comunque fissa, un rettangolo, mentre per le viste, la differenza è che la linea di contorno è tratteggiata, e via dicendo, e ogni modalità ha un particolare significato.
La mia idea sarebbe quella, magari, di poter selezionare un'altra forma di base, chessò, una sfera (è un esempio...). Diciamo che mi piacerebbe creare una specie di set di template, selezionabili, a cui poi aggiungo gli elementi relativi al tipo di oggetto.
Comunque, a parte questo, ora che ho anche modificato la gestione dei singoli oggetti, il disegno è ora piuttosto veloce, al massimo un tempo di refresh di 1 secondo, anche per quanto riguarda lo zoom.
Diciamo che, la rivoluzione fatta in queste due sere è tutta colpa tua... :P
-
Diciamo che, la rivoluzione fatta in queste due sere è tutta colpa tua... Linguaccia
be visto che è stata una rivoluzione con finale a lieto fine direi che non è stato tempo perso :2birre:
-
Bè, visto che pgDesigner lo scrivo quanto ho tempo libero, e non perso..., anche la risoluzione dei problemi non lo è...
Dato che Gambas ha ancora dei limiti nella gestione delle classi, la mia paura è sempre quella di dover andare a toccare troppe cose, per sistemarne una.
E' però anche vero che questo lo faccio, da un verso, anche volentieri e pure velocemente, ma mi dà un pò di fastidio a mettere le mani su cose su cui pensavo di aver trovato il bandolo della matassa.
Ad ogni modo, dato che avevo predisposto il programma in un certo modo, cercando di lasciare spazi ad eventuali e varie future, dopo in minimo di studio le modifiche introdotte non sono state così esagerate, diciamo molto limitate, meno male...
Devo dire, infine, facendo anche un critica, ma sapendo che la cosa sicuramente migliorerà con il tempo, che Gambas quando si affrontano certe logiche diventa alquanto complicato a causa dei suoi attuali limiti...