Gambas-it
Vari => OpenBar => Topic aperto da: fsurfing - 15 Marzo 2008, 19:37:17
-
ciao a tutti,
avrei bisogno di iserire in un form una drawingarea di dimensioni 2000 per 2000
logicamente tale dimensione non ci sta in un form 1280 x 1024.
si possono inserire delle barre di scorrimento? ed eventualmente zoomare la drawingarea?
-
Certo!!!
La metti dentro una ScrollView.
Bye
-
grazie mille! :-)
ma volendo si può zoomare la drawingarea?
-
Si, anche, usando i metodi MoveScaled e ResizeScaled, se non sbaglio.
-
perfetto !! dovrebbero essere loro! :-)
chissa perchè non ho controllato nei metodi prima di chiedere!! :leggere:
grazie mille!!
-
Già... :evil:
-
certo che se tutti leggessimo tutto cesserebbe lo scopo di questo sito!
inoltre discutendo si può giungere a modi diversi di fare la stessa cosa ognuno con i suoi vantaggi e svantaggi..... o sbaglio? :amici:
-
Il tuo, giustamente, è un appunto su quanto ho scritto nei "Suggerimenti", e dico "Suggerimenti" perchè quello era lo scopo; comunque ho già risposto lì.
Sono d'accordo con te per quanto riguarda la discussione in amicizia, e io sicuramente continuerò a farlo, dopotutto non volevo assolutamente criticare; io ti ho risposto tranquillamente e credo tu mi abbia travisato leggendo quel post, in cui non facevo riferimento direttamente a te, ma facevo notare semplicemente delle cose, a mio avviso, segno di qualche piccola mancanza.
Comunque, per ritornare nella discussione in amicizia, hai provato quelle funzioni ?
:2birre:
-
:2birre:
si si le ho provate, anche se solo velocemente, sembrerebbero proprio ideali per quello che vorrei realizzare in futuro. Grazie mille del tuo aiuto
tra l' altro leggendo i vari metodi dell' "componente DRAW mi sono saltate all' occhio alcumi metodi tipo POP e PUSH che si riferiscono ad una trasformation matrix. il concetto mi incuriosisce, tu che hai più esperienza sia in gambas che in molti altri linguaggi di programmazione sai a cosa si riferisce e se può essere utile per velocizzare le oprezioni di disegno?
-
Bè, esperienza è una parola grossa, almeno per quanto riguarda Gambas...
Però ho riscontrato un certo numero di problemi riguardo la grafica, in particolare con l'interattività con gli oggetti che inserisci nel disegno.
Facendo presente che gambas è un linguaggio interpretato, la velocità a volte non è il suo forte, anche se, facendo prove ad esempio con python, ho notato che le stesse identiche cose hanno una velocità paragonabile al C.
Anche in java ho fatto delle prove, e devo dire che rispetto alle precedenti versioni, queste ultime sono migliorate parecchio, e anche in questo si sono avvicinate a linguaggi di basso livello, come è il C.
In python, una cosa che mi ha stupito, è la molteplicità e la varietà di oggetti, e la potenza del linguaggio; se agganci a questo le librerie wxpython, fai delle cose strabilianti. La cosa bella che ho notato e provato è un oggetto, simile a DrawingArea, che si mantiene in modo distinto gli oggetti grafici che ci disegni sopra. Per fare un esempio, pensa a Drawing Area, tu ci disegni un rettangolo, ma poi per muovere questo rettangolo con il mouse, ti devi gestire tutti gli eventi, tenendo conto della posizione e delle dimensioni, della presenza di altri oggetti, ecc.; in python, l'oggetto viene sì mantenuto e riprodotto sulla DrawingArea, ma ha un suo corpo ben distinto, per cui attivando opportunamente gli eventi del mouse, lo puoi muovere senza alcuna percezione di lentezza.
In pgDesigner (che ho scritto in gambas) ho avuto modo di fare moltissimi esperimenti con la grafica e l'interattività con gli oggetti che vi disegnavo sopra, ma a tutt'ora non sono riuscito a risolvere il problema velocità. Quanto il numero di elementi disegnati diventa un numero considerevole, e magari le dimensioni della DrawingArea sono molto grandi, il movimento diventa lentissimo, a causa del necessario repainting del grafico.
Come avrai sicuramente notato, gambas si appoggia pesantemente a librerie esterni (vedi gtk e qt), e fà uso delle funzionalità contenute in queste librerie ma, a mio avviso, perde qualcosa per strada.
In situazioni normali non si nota alcun problema, sia per quanto riguarda la grafica, sia per il resto, ma se vuoi qualcosa di più gestibile e controllabile, sorgono i problemi.
Attualmente stò provando a riscrivere il motore grafico del mio pgDesigner ma, a parte piccolissime ottimizzazioni indipendenti dall'oggetto DrawingArea, non riesco a migliorarne la gestione.
Ad ogni modo, se tu non hai di queste necessità, và tutto bene.
-
veramente volevo farmi un piccolo cad per impianti elettrici ...
avevo già iniziato tempo fa e come dici tu in quando si raggiunge un certo numero di oggetti da disegnare il refresch diventa lunghino.
per ora risolvo disegnando tutto ciò che non devo muovere in una picture, il refresh ridisegna direttamente la picture salvata più l' oggetto da muovere
-
Infatti è quelo che avevo utilizzato io, e la cosa sarebbe stata semplice, se non fosse che nel mio grafico devo disegnare delle linee e altre cose, che dipendono dalla posizione degli altri oggetti.
Purtroppo, con tutte le prove che ho fatto e eseguo tutt'ora, non riesco a trovare un modo per risolvere.
Ma il problema maggiore è che in effetti NON C'E' MODO di risolvere, proprio per le causa che ti avevo descritto.
Anche in altri linguaggi, inizialmente, avevano lo stesso problema, ovviamente parlando di linguaggi interpretati, e l'hanno risolti piano piano. In gambas credo che tocca aspettare un pò per arrivare a quel livello.
Quindi, per farla breve, tocca accontentarsi della situazione attuale, cercando di ottimizzare il proprio codice; a meno che un esperto in C, che abbia tempo a disposizione, non si metta sotto a creare una libreria migliore.
-
Parlo da profano... ed utilizzare le OpenGL, visto che Gambas permette di gestirle nativamente con un componente ad oc?
Risolvete il problema della velocità in un secondo demandando tutto alla GPU.
-
Potrebbe essere una soluzione, ma le librerie opengl sono un pò ostiche da far funzionare, anche in altri linguaggi, oltre che pure un pò vecchiette...
Avevo pensato di farlo, probabilmente appena finito l'aggiornamento della mia Fedora ci provo.
Vi faccio sapere.
Ciao
-
Caro Luigi, i tuoi interventi sono sempre molto stimolanti. Riflettendo sulle componenti grafiche fornite da Gambas, mi chierdevo se sara' mai possibile a questo punto costrurci un 'query builder' alla Access o alla sqlitemaestro. In questi casi, sono utilizzati gli eventi di spostamento del alcuni oggetti.
-
Grazie andy !
Comunque, a parte quanto ho scritto, la drawingarea è sempre utilizzabile, non ho detto di no; solo che in particolari situazioni è piuttosto fastidioso il fatto della lentezza. Il problema comunque si presenta con aree molto grandi, se questo non è necessario, la velocità è apprezzabile anche con diversi oggetti disegnati sopra. Diciamo che il problema non è il disegno vero e proprio, ma le dimensioni dell'area di disegno; purtroppo, credo ci sia ancora da lavorare in gambas, nell'uso delle librerie esterne (es. kde, gnome, ecc.), sicuramente devono essere ottimizzate, perchè al di fuori di gambas, queste sono molto veloci, e questo di può vedere in pratica già dall'ambiente desktop.
In altri linguaggi, anche se interpretati, il divario sembra non esserci più; come ho scritto, già in python che in java, la velocità non è più un problema.
-
mi piacerebbe studiare python ma dovresti dirci con quali strumenti utilizzarlo, cosi' tanto x fare le cose + veloci...(ide o eventuale editor preferito....ecc). domandina gambas: se devo implementare un oggetto da spostare, devo usare la drawing area? non posso draggare qualunque oggetto?
-
@md9327:
le OpenGL non sono vecchiotte. Sono ottime librerie grafiche che la Microsoft vuol far credere siano delle ciofeche ;-)
E se anche così non fosse, sotto Linux non hai altro :-P
-
Rispondi subito a leo: sai che non sono amante di ms, però ti confermo che le opengl sono vecchiotte, anche se funzionano e sono le uniche sotto linux. Mica sono contrario ad usarle, solo che sono un pò ostichette... :-)
Comunque, ora stò combattendo con l'aggiornamento della distro, appena posso ci faccio qualche prova e vi dico... Dal semplice esempio fornito con gambas, si vede la loro potenza, e probabilmente, se ci riesco, adotterò quella strada; per ora ci provo...
Caro andy, per python esistono un mucchio di librerie che neppure immagini però, a parte prodotti commerciali, non c'è molto software, ovvero ambienti ide che ti permettono, come per gambas, di costruirti graficamente le finestre (per esempio...). Tutti gli ambienti ide che ho provato (open, ovviamente) hanno molte cose relative agli editor e al debugging, ma poco o nulla che riguarda la parte grafica. Le librerie wxWidget, per esempio, hanno tutto quello che serve per la parte grafica (e non), ma l'unico ide che le utilizza in maniera non testuale è wxDesigner che è commerciale (anche se non costa poi molto).
Data la mia provenienza dal C/C++, posso dirti che python è un linguaggio molto potente e paragonabile quasi ad un linguaggio a basso livello, e probabilmente più potente di java (che mi pare venga utilizzato più per la moda del momento, che per altro...).
Ue!!! Con questo non voglio dirti di passare al python !
E' pure normale che quel linguaggio sia così potente e diffuso, dopotutto è un bel pò che è in giro, e ci lavora un mucchio di gente in giro per il mondo.
:-)
Per rispondere alla domanda sulla drawingarea, posso dire che se vuoi utilizzarla per disegnare oggetti più o meno rettangolari, senza linee ecc, potresti abbinarla con l'oggetto PictureBox. Dato che la PictureBox è un oggetto di tipo window, il motore del movimento è gestita dalla libreria; tu non devi far altro che disegnarci su il contenuto, e associarla alla drawingarea, oppure anche ad un semplice Panel. Set tutto questo lo metti dentro una ScrollArea, puoi crearti un ambientino da disegno, praticamente come ho fatto io con pgDesigner. Questo ovviamente se non devi disegnare qualcosa di diverso...
-
Mi intrometto anch'io nella questione dei linguaggi di scripting perché tempo fa fui tentato di impararne uno anch'io...
Come tutti, iniziai col Python, che però ho abbandonato non appena ho iniziato ad addentrarmi un po' nella lettura di uno dei tanti "tomi" che si trovano in libreria. Non mi piaceva....
Mi sono avvicinato allora al Ruby ed ho trovato un linguaggio ugualmente potente ma più "naturale" nei suoi costrutti e più orientato agli oggetti di Python. Ed ho deciso di acquistarmi l'ennesimo tomo da leggere la sera prima di addormentarmi ;)
Il problema di questi linguaggi, però, come ha fatto presente md, è la gestione delle GUI. Di proprio si appoggiano a schifezze di librerie: Ruby, ad esempio, usa le Tcl/Tk versione 8.4 mi pare, in pratica sono le GTK1: la resa è orribile se paragonata alle interfacce moderne. E per costruire qualcosa di serio devi usare uno dei tanti binding verso qualche libreria più diffusa. E qui entri in un ginepraio da cui non esci più.... Ci sono le Qt, le GTK, le FOX, le wxWidgets ecc...... ma generalmente bisogna fare molto lavoro a mano perché di GUI builder mica ce ne sono tanti... Forse l'accoppiata migliore su Linux è usare le GTK e Glade per costruire le interfacce. E poi c'è il problema dell'IDE per scrivere il linguaggio: essendo linguaggi interpretati e di scripting, sono in continua evoluzione per cui spesso negli IDE mancano diverse caratteristiche a cui chi ha lavorato sugli ambienti tipo Gambas mancano (una fra tutte, per me che sono smemorato assolutamente fondamentale) è il completamento automatico.
Insomma, non è così semplice come sembra...
Io alla fine son rimasto a Gambas perché, nel bene o nel male, è un ambiente che integra tutto quello di cui ho bisogno: IDE per la scrittura del codice con autocompletamento, GUI builder, compilatore.
-
Concordo con te. Gambas è un ottimo compromesso. Io poi gia' impiego un botto di tempo a costruire software con Gambas figurati con gli altri :-)
-
Leo ha detto cose giuste.
In effetti, qualunque linguaggio usi, hai dei vantaggi ma anche svantaggi.
Almeno per me, data anche la mia veneranda età :-) , di linguaggi ne ho visti e usati parecchi, ognuno aveva le sue peculiarità ma anche le sue pecche.
Ho lavorato con C/C++ per 16 anni, in contemporanea usavo il DB2Plus (chi se lo ricorda?), Clipper e Basic; poi, con la nascita di windoz, tutto è stato portato su un'altra dimensione, forse a mio avviso anche discutibile, comunque un'altra era. COmunque, la faceva sempre da padrone MS, anche se in settori sistemistici già si usavano linguaggi di scripting. Con linux è esploso tutto, più libertà alla fantasia, poca spesa per affrontare un problema (non eri costretto per forza a comprare un pacchetto MS), sperimentazione, ecc. Da lì sono nati un mucchio di progetti, linguaggi, applicazioni, e così via, insomma il boato.
Fate un pò il conto di quanti linguaggi, non dico applicazioni end-user, che ci sono in giro, alcune molto pubblicizzate, altre molto potenti, altre facilmente assimilabili (come gambas...), e tutte hanno le loro caratteristiche e pecche; però se ti fai prendere da uno solo di questi, poi è difficile che lo molli, tant'è che ne conosci alla fine tutti i particolari, hai pure contribuito a farlo crescere...
Fai bene andy a buttarti su gambas, è una scelta, e se ti ci incaponisci sopra alla fine potrai dire di conoscere il linguaggio.
Una cosa ti posso dire con sicurezza: alla fine utilizzarne un'altro diventa più facile, perchè anche se diversi tra loro, tutti i linguaggi (e non solo) hanno e avranno sempre qualcosa che li accomuna, come le capoccie di noi poveri programmatori... :-)
Che filosofia, eh? :lol: :lol: :lol:
-
@md9327
Tu almeno sei riuscito a fare quel salto di qualità, che io invece non son riuscito a fare.
Forse la mia età è più veneranda della tua (ne ho 59) ed ho "consumato" il DB2 DB3 e DB4 oltre che il Clipper il FoxPro ed il VBA, e proprio a causa della loro particolare sintassi, non sono mai riuscito a digerire gli ambienti che usano le parentesi graffe solitarie ed il cui codice non è così compatto come lo è in gambas.
Se ricordi bene, il linguaggio di interrogazione del DB3 era dotato di una potenza incredibile, potenza che ancora oggi rimpiango, e che ti permetteva addirittura di lavorare su un database in modo interattivo.
Oggi queste cose le puoi fare solo in ambienti tipo Calc o Excel, ma è un altro modo di lavorare.
Ecco perchè considero gambas un ottimo compromesso, perchè come dice Leo, tutto sommato ha tutto cio che serve, o quasi.
Ma so che diverrà sempre migliore, ci conto proprio!
-
Acc... sei più vecchio tu! :-)
Sì, ricordo tutto quanto, anche perchè quella era l'epoca della nascita del computer in genere, e io ci sono stato dentro fino al collo; pensa che ho iniziato proprio con l'hardware, poi mi sono butto anche nel software.
Sì, adesso il modo di lavorare è diverso, ma è anche vero che molti giovani, traviati da questo modo di lavorare, non hanno basi di conoscenza adeguate per capire il perchè delle cose; mi dispiace dirlo ma è così, ci lavoro tutti i giorni a contatto, e se ne rendono conto pure loro...
Riguardo gambas, da parte mia lo considero una buona idea, anche una delle tante, e soprattutto coraggio ad implementarla su linux. Su linux servono queste cose, a parte contrastare il dominio di MS, anche per avere una più vasta variatà di possibilità sotto questo sistema operativo.
Penso anche io che crescerà, anche con il nostro aiuto, e crescerà come hanno fatto altri linguaggi. Abbi fede!
Viva Gambas !!! :-)
-
Continuo ad essere off-topic, ma concludo dicendo:
anche io ho proprio iniziato con l'hardware, con le logiche digitali TTL e poi piano piano contatori, decodifiche, memorie e processori.
Ho iniziato col binario per passare poi all'assembler sull'8080 e lo Z80, ma quando le cose si son fatte più complesse e complicate, complice anche una spiccata esigenza di lavoro, ho dovuto per forza passare ai linguaggi evoluti dimenticando piano piano il passato.
Oggi invidio profondamente chi riesce ancora a manipolare i registri del micro, cosa che ho progressivamente abbandonato quasi trent'anni fa.
Sono menti eccelse per me, coloro che ancora riescono a farlo!
Evviva Gambas!
-
Tanto visto che sei fuori topic tu...
Ricordo e ho iniziato anche io in quel modo ma, come dici tu, per lavoro si è passati ad altro. Io, per quanto posso, cerco di tenermi aggiornato, ma è difficile, non si può stare dietro a tutto, anche se la voglia c'è.
Ho ancora il tester, qualche analizzatore perso da qualche parte, il mio tavolo di lavoro... ma ormai sono poche le volte che mi metto... Tra l'altro non ci vedo un piffero a saldare i piedini di un integrato... cavolo !!!
:-) Ricordi... vabbè... :-)
-
Purtroppo l'usare un linguaggio evoluto è oggi una necessità. Pensate a chi scrive un software come Photoshop oppure un gioco come Quake3 se lo dovesse fare INTERAMENTE in Assembly!
-
Forse funzionerebbe... :-)
No, scherzo!
Il problema dei linguaggi moderni è la virtuale necessità di avere un ambiente grafico, per cui un'applicazione deve essere composta dal 95% di codice per gestire la grafica, e il restante 5% per la logica vera e propria. La cosa bella è che l'utente, attratto dal luccicare delle finestre, tutte belle e carine, poi non si rende effettivamente conto se sotto c'è effettivamente quello che serve veramente; e le applicazioni fanno sempre più pietà, piene di bachi, inutilmente troppo grosse per poter essere gestite e manutenute in modo umano.
Poi teniamo conto che basta metter su un gruppo di ragazzini, che conoscono un pò di linguaggio, che costino poco, e si tira su un sistema... Questo senza badare, anzi, fregandosene altamente della qualità... non dico altro, e ce ne sarebbe da dire.
Purtroppo noto questa cosa sempre su più vasta scala, in piena espansione e, a questo punto, si vende tutto e si passa tutto per applicazioni serie, di cui non si può farne a meno. Un pò come i telefonini, le auto, ecc... Diciamo che siamo entrati nel mondo della moda... :-)
Ovviamente non parlo di imparare e/o sperimentare, come facciamo noi qui per esempio in questo sito, ma del lavoro in particolare; di esempi ce ne sono a bizzeffe, a cominciare dai sistemi operativi...
Con questo non voglio nulla togliere a tutto quello che si è creato o è nato a livello collaterale, ovvero all'espasione che si è avuta del computer e la possibilità di avere un maggior numero di persone a lavorarci sopra.
Se penso che per fare la stessa cosa, prima utilizzavo pochi Kbyte di memoria, mentre ora ci vogliono carrettate di giga... Prima si stava attenti al bit, ora ce ne freghiamo altamente, compriamo un pc più potente!
Ho usato lunguaggi che per scrivere il classico "Ciao mondo", si portavano appresso 300/400Mbyte di librerie... E' perchè ? Ma che ti frega ! Compra una macchina più potente ! Fai costruire ad Intel un chip con 64 processori interni con 20G di memoria, poi incarica MS di creare un windows vista con i pulsanti, con le stelline luccicanti, che metre aspetti due ore per l'apertura di una finestra, ti fà intanto un caffè brasiliano, così il tizio davanti il computer non bestemmia turco per il ritardo, magari solo per scrivere una semplice email...
Per ritornare al discorso di photoshop o quake, ricordo che sono nati un migliardo di anni or sono, e strutturalmente non sono cambiati se non per la grafica. Il motore di base del gioco è identico a quello che girava su dos, sempre un milione di anni or sono... :-)
Scusate, mi sono lasciato andare un pochino... :-)
Comunque, la riflessione è quasi d'obbligo...
Bye
-
E' vero.
Io mi sono accorto, nel passaggio da Windows a Linux, di quanto fossero più piccoli gli eseguibili del Pinguino rispetto a quelli di Bill.
Perché Linux è ancora (chissà per quanto) a livello di sistema per hacker, termine inteso nel senso buono: cioè persona che si sforza di imparare come funzionano le cose e di superare i limiti delle stesse.
Siccome si ha a che fare con un sistema che, bene o male, è supportato meno dagli sviluppatori hardware, i programmatori si sforzano ancora di spremere tutto il possibile e con il meno possibile. Se pensiamo a cosa fanno ad esempio Compiz con poche centinaia di Kb di codice in relazione a quanto peso è Vista per effetti secondo me assolutamente inferiori...
In questo, poi, le architetture chiuse erano forse molto più vantaggiose: venivano spronati i programmatori a tirar fuori dalle stesse tutto il possibile. Vi ricordate ad esempio i primi giochini che uscivano insieme ad un home computer degli anni '80, ad esempio C16, C64, Amiga? Erano orribili!!! Poi, dopo qualche anno, facevano fuoco e fiamme. Questo perché la macchina era sempre la stessa ed i programmatori pian piano la imparavano a conoscere e col tempo tiravano fuori da essa ogni goccia di potenzialità.
Fallo oggi! Ogni 6 mesi devi cambiare scheda grafica o processore, altrimenti non fai più girare il gioco di ultima generazione...
-
Purtroppo è vero... hai detto tutto giusto... è comunque solo uno scopo commercialistico...
Me è pure vero che è così che uno impara, non è aver la pappa pronta che ti fà crescere, su linux è così ed è per questo che mi piace, il poter esprimere le mie capacità, sforzare la mente nel risolvere problemi, anche inventarli magari...
Se prendi un software che ti fà tutto, alla fine che gusto c'è?
E poi, comunque, per fare un buon software serve sempre un buon programmatore.
Se prendiamo ad esempio i videogiochi, che a me comunque non interessano (preferisco andare a pesca...), comunque c'è qualcuno con le p... che si inventa i motori, e questi sono a bassissimo livello, altrimenti non gira nulla...
Pensa a java, che ora và di moda e sembra che non se ne può fare a meno... ma tu come credi possa girare ? Non pensi abbia bisogno di un numero di motori di base, diversi per sistema operativo, che la fanno girare ? L'idea è buona, permette di far girare lo stesso codice, interpretato, su diversi sistemi ma, ad ogni modo devi per forza creare motori diversi. Se togli questi motori sottostanti, che ne sarebbe di java? Questo ovviamente riguarda tutti i linguaggi interpretati (vedi perl, python, php, ecc...), posso girare ovunque, ma le librerie di base sono diverse e fatte, guarda caso, tutte in C/C++ se non addirittura in ASM.
Io, che sono anche uno smanettone, e provengo da un periodo dove tutto questo non esisteva, e si doveva per forza inventarsi le cose, risparmiando sul bit, bè... preferisco quei tempi, che comunque hanno forgiato gente capace (non parlo di me, ovviamente :-) ), persone capaci di giudicare un programma, e di stare ancora attenti al bit, nonostante le idee odierne...
Comunque, questa è una bella discussione, solo che credo non era questo l'ambito, e credo si potrebbe spostare da altra parte più appropriata del forum... che ne dici webmaster ?
-
Spostata... me n'ero accorto che ormai andavamo off-topic alla grande ma, sai, la voglia di fare 4 chiacchiere era tanta che poi ho lasciato stare.
Cmq è vero che nei bei tempi andati si faceva attenzione ai bit: io ho iniziato con un Commodore 16, dove la RAM libera era di 16 KB ma, tolto lo spazio per le variabili e qualche altra menata, usabili dall'utente 12 KB!
In 12 KB ci rientravano fior di programmi. E quando passai al PC XT, con 640 KB mi pareva di essere "arrivato"! Caricavo l'MS-DOS in un ramdisk e poi lanciavo tutto al volo! Fallo oggi... hai bisogno almeno di Giga e Giga di RAM. Una volta ti connettevi all'hardware in maniera diretta e comandavi i singoli pixel con poche istruzioni. Mi ricordo che col C16 di cui sopra potevo con un semplice POKE 3072,65 mettere una "A" nella prima locazione della memoria video: in pratica appariva il carattere in alto a SX. Fallo oggi, senza nessun framework sottostante...
Ben vengano i progetti come Damn Small Linux che in soli 50 MB includono non solo un ambiente grafico ma anche una dotazione software di tutto rispetto. In questa maniera si fa capire a chi di dovere che c'è anche un'altra via per far le cose.
-
Dopo aver letto i vostri commenti non nascondo che una lacrimuccia è apparsa in un angolo dell'occhio.
Concordo con quanto detto da tutti voi e ribadisco un concetto che ritengo sia alla base di qualsiasi linguaggio di programmazione ed in particolare del Basic (e di conseguenza di Gambas):
le istruzioni base sono poche, veramente poche e tecnicamente con esse si può ottenere tutto.
Faccio un'esempio, "split": serve a suddividere in pezzi una determinata stringa racchiudendo in un array le singole estrazioni.
Bene, questa funzione comodissima è altresì ottenibile mediante un ciclo FOR..NEXT con all'interno un IF..THEN che controlli se il carattere di suddivisione è presente e conseguentemente mettere la parola racchiusa da una posizione iniziale alla nuova all'interno di un array precedentemente creato.
Ovviamente usare "split" è più comodo, semplice e funzionale.
Questo discorso per dire cosa? Semplice, non cercate funzioni specifiche alla soluzione di un problema ma trasformate il problema in codice grezzo, in questo modo avrete 2 vantaggi:
1° maggiore conoscenza e padronanza dei comandi base
2° sviluppo di soluzioni per qualsiasi problema vi si ponga.
Per concludere e dire qualche cosa di attinente al titolo della discussione:
sto studiando una serie di possibili soluzioni al problema di rapidità di esecuzione della drawing area e credo che alcune strade siano abbastanza percorribili, spero nei prossimi giorni di potervi mostrare qualche cosa.
Ciao
-
Intanto un bravissimo a leo che, prontamente e velocemente, ha spostato tutto questo malloppone di discorsi... :-)
In effetti stà iniziando ad avere dimensioni piuttosto corpose, ma tra nostalgici mi pare normale... :-)
(e non dico vecchietti... eh darth ?) :-)
S, è vero pixel, se ho ben capito quello che hai scritto, in effetti secondo me è necessario avere una più ampia visuale sulle possibilità di risolvere un problema software; alla fine ti accorgi che i modi per affrontarlo sono molteplici, anche se alla fine è necessario adottarne uno solo che sarà poi quello più idoneo al caso. Questo ovviamente non vuol dire che poi quella soluzione andrà bene a prescindere dovunque, sicuramente ti dà l'esperienza di affrontare il prossimo problema, per poterlo affrontare in modo ancora migliore.
I punti che hai elencato, per chi conosce un pò di assempler, alla fine sono le istruzioni passo passo che dovevi scrivere per qualsiasi cosa: prendi il byte, metti nel registro, somma questo, sottrai quell'altro, ecc...
Riguardo alle prove sulla drawing area, spero che tu trova qualcosa che possa migliorarne la gestione; io le ho provate QUASI tutte, tranne usare le "GL", come suggerito leo.
Ora che dovrei aver messo un pò a posto il mio sistema, dopo gli aggiornamenti della distro, dovrei essere in grado di riprendere lo studio del problema grafico, anche perchè devo necessariamente risolverlo per il programma pgDesigner. Ho già fatto delle prove con altri linguaggi, e le differenze con gambas sono eccessive, per cui è necessario capire com'è possibile migliorare la situazione (sono un pò caparbio su queste cose, e il problema non mi và proprio giù...)
-
I punti che hai elencato, per chi conosce un pò di assempler, alla fine sono le istruzioni passo passo che dovevi scrivere per qualsiasi cosa: prendi il byte, metti nel registro, somma questo, sottrai quell'altro, ecc...
Come ci capiamo :-) (anche se personalmente è dal lontano 1985 che non tocco più l'assembly)
Riguardo alle prove sulla drawing area, spero che tu trova qualcosa che possa migliorarne la gestione; io le ho provate QUASI tutte, tranne usare le "GL", come suggerito leo.
Personalmente scarterei l'ipotesi GL per due semplici motivi:
1) un caos assurdo di utilizzo, se prendi l'esempio Gambas-gears capisci cosa intendo ed inoltre l'assoluta mancanza di documentazione a riguardo su come viene implementato in Gambas, ho provato leggendo il tomo delle specifiche ma c'è da diventare vecchi prima di aver tracciato una linea;
2) con schede video ATI che usano driver fglrx avvengono dei fastidiosi effetti di flickering ed una gestione sballata del framerate.
Ciao
-
Bè, questo l'avevo ipotizzato già nelle precedenti rispondendo a leo... Non mi sono mai impegnato nel linguaggio opengl, ma ho conosciuto alcuni che me hanno parlato come appunto nei parlato tu.
Ad ogni modo, a meno di non creare un gioco o un'applicazione grafica ad alto livello, opengl è sicuramente da scartare.
Il problema, come ho più volte scritto, e dalla mia esperienza con l'utilizzo in gambas, è che credo che la drawingarea abbia delle lacune, che probilmente si risolveranno in seguito. Come pure ho scritto, ho fatto delle prove con oggetti analoghi, sia in python che in java, con risultati molto buoni, per cui credo che la cosa dipenda da come è stato implementato l'oggetto e il collegamento con le librerie qt/gtk. Dato che dò per accertato che queste ultime non sono la causa dei problemi di lentezza, e dato per accertato che le istruzioni che ho usato sono, più o meno, le stesse che ho utilizzato per gli altri linguaggi, penso che il punto cruciale sia proprio la libreria gambas.
A questo punto è probabile che, solo per avere una libreria per poter disegnare con gambas, sia stata creato creato questo oggetto (e anche altri), e probabilmente non sono state adottati dei metodi per velocizzare al massimo il link con le librerie esterne.
Ora, dato che non ho ancora dato un'occhiata al codice sorgente in C di gambas, non posso dare ulteriori opinioni, ma solo supposizioni date dall'esperienza. Se riesco ad avere il tempo necessario per analizzarle più o meno a fondo, potrò dare un risposta più mirata.
Ad ogni modo, se fai delle prove anche tu, possiamo riunire i risultati per capire se riusciamo a trovare alternative migliori.