Autore Topic: DrawingArea  (Letto 5575 volte)

Offline leo72

  • Amministratore
  • Senatore Gambero
  • *****
  • Post: 2.163
    • Mostra profilo
    • http://www.leonardomiliani.com
Re: DrawingArea
« Risposta #30 il: 27 Marzo 2008, 14:20:19 »
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.
Visita il mio sito personale: http://www.leonardomiliani.com

Offline Pixel

  • Amministratore
  • Maestro Gambero
  • *****
  • Post: 414
    • Mostra profilo
    • http://www.gambas-it.org
Re: DrawingArea
« Risposta #31 il: 27 Marzo 2008, 15:53:49 »
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
Ubuntu Italian Member Ubuntu User 4683
Il mio Blog

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: DrawingArea
« Risposta #32 il: 27 Marzo 2008, 16:28:20 »
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ù...)

Offline Pixel

  • Amministratore
  • Maestro Gambero
  • *****
  • Post: 414
    • Mostra profilo
    • http://www.gambas-it.org
Re: DrawingArea
« Risposta #33 il: 27 Marzo 2008, 16:57:42 »
Citazione

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)

Citazione

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
Ubuntu Italian Member Ubuntu User 4683
Il mio Blog

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: DrawingArea
« Risposta #34 il: 27 Marzo 2008, 18:44:05 »
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.