Macworld Expo 2005: Mac mini e iPod shuffle

[cdimauro]

x samslaves: bella la tua storia.
Anch'io alla scuola superiore mi sono scontrato con i PC e i pacchetti Borland usati per programmare, ma mi devo dire che mi sono piaciuti molto e ne ho sempre desiderato un porting per Amiga. Infatti a casa avevo un Amiga 2000 con 1MB di ram, e usavo un lentissimo emulatore PC per lavorare col Turbo Pascal.

[samslaves]

>Una curiosità: cosa te ne fai dei file .NIB? <

Nella maggior parte delle tools C++ e Java (lo stesso VB) lo sviluppatore subclassa le classi standard e scrive linee di codice per fare in modo che i controlli o le finestre ad esempio, sebbene usino un RAD che permetta di posizionarli e definirne certe caratteristiche, rispondano ad eventi o interagiscano tra di loro e con la logica dell'applicazione. Usando l'Interface Builder (gia' dal NeXT poi OpenStep e ora OS X) non si ha a disposizione un RAD classico; una volta posizionati i controlli ecc... non si deve scrivere codice per gestire interazioni tra finestre, controlli e logica. Si usano connessioni grafiche. I files NIB (Next Interface Builder) conterranno tutte queste informazioni. Sono files che contengono non codice (classi) ma oggetti gia' istanziati con informazioni sulle connessioni/azioni verso o da altri oggetti (ad esempio quelli della logica dell'applicazione). A differenza delle altre tools quindi nel codice non troverai mouseDown ecc... ma tutto questo e' trasparente non ti interessa. Inoltre l'interfaccia non viene creata a runtime quando il codice viene eseguito, ma si trova gia' congelata su disco. Poi puoi proseguire anche nel modo classico, ma questo ha fatto (a suo tempo) la fortuna di OpenStep a livello Enterprise e per i centri tipo CIA (ne ordinarono a migliaia) dove il rapid prototyping (vero) era necessario. Il primo browser fu creato su di un NeXT Cube cosi'. Poi Sun, per beghe interne, passo a Java riportandoci indietro di 10 anni.

[melarido]

Originariamente inviato da cdimauro
OK, hai ragione. Mi riferivo al Window Buffer, non al Frame Buffer.

Il concetto di "window buffer" citato dall'articolo non ha riscontri (nell'articolo) con una sua controparte in windows per cui, mi spiace, ma continuo a non vedere un paragone calzante in quello che scrivi. Si citano invece le evidenti differenze tra Classic ed OS X ed è abbastanza ovvio che non puoi gestire un'interfaccia come quella di osx con "roba" tipo GDI, come emerge dallo stesso articolo. In ogni caso già al rilascio di Prelude sul sito di sviluppo c'erano abbondanti documenti sull'implementazione di OpenGL.

L'articolo a cui ti riferisci è infatti scritto sulla release 10.1 (settmbre 2001) e Quartz non si appoggiava su OpenGL. Il discorso dell'autore è piuttosto oggettivo a riguardo:


But like much of the rest of OS X, pervasive window buffering is slightly ahead of current state of hardware. Long-term, this is also a good thing, in my opinion. It's easier to wait for hardware to catch up to your ambitious (but clean) software architecture than it is to try to revamp your operating system in response to advances in hardware (just ask Apple ;-)

Quindi non è che sia una novità il sistema di gestione delle finestre di OS X. E ribadisco che non è certo il migliore, in termini di consumo e frammentazione della memoria: da questo punto di vista Windows e Mac OS Classic sono certamente migliori,

Le risorse sono a disposizione di chi le usa, che poi non le sappia usare al meglio perchè non ha voglia di cambiare è sempre un discorso a parte.
Avalon lavorerà su DirectX per gli stessi motivi per i quali Quartz usa OpenGL. Quartz è stato il primo della sua "specie" ad usare un'API che sfrutta le gpu per la gui. E' una novità.

Poco importa cosa potevi fare con l'Amiga, al tempo qualsiasi applicativo "intensivo" veniva scritto col compilatore da un lato e l'editor binario dall'altro, non c'era certo il livello di astrazione nello sviluppo raggiunto oggi nè la stessa integrazione, nè le stesse funzionalità nelle interfacce.

[FaveDiFuca]

Originariamente inviato da cdimauro
Il fatto che tu l'abbia installato non vuol dire niente: si può comprare? No. Fine della questione.

Ciao.
Ti quoto qui perché in altre occasioni hai fatto lo stesso discorso per Longhorn

W la gina sempre

[cdimauro]

Originariamente inviato da melarido
Il concetto di "window buffer" citato dall'articolo non ha riscontri (nell'articolo) con una sua controparte in windows per cui, mi spiace, ma continuo a non vedere un paragone calzante in quello che scrivi.

E come può esserci un paragone se non c'è un equivalente? Mi sembra normale, no?
La questione è nella modalità con cui ogni s.o./applicazione effettua la gestione, e di conseguenza il redraw, degli oggetti grafici.

Si citano invece le evidenti differenze tra Classic ed OS X ed è abbastanza ovvio che non puoi gestire un'interfaccia come quella di osx con "roba" tipo GDI, come emerge dallo stesso articolo.

E' chiaro che sono due GUI diverse, e hanno esigenze diverse. D'altra parte Windows gestisce il tutto usando la GDI, che da anni ormai è implementata in hardware nelle GPU.

In ogni caso già al rilascio di Prelude sul sito di sviluppo c'erano abbondanti documenti sull'implementazione di OpenGL.

L'articolo a cui ti riferisci è infatti scritto sulla release 10.1 (settmbre 2001) e Quartz non si appoggiava su OpenGL. Il discorso dell'autore è piuttosto oggettivo a riguardo:
[...]
Le risorse sono a disposizione di chi le usa, che poi non le sappia usare al meglio perchè non ha voglia di cambiare è sempre un discorso a parte.

Già, ma vedi sopra: se le risorse vengono comunque usate, qual è il problema?

Avalon lavorerà su DirectX per gli stessi motivi per i quali Quartz usa OpenGL. Quartz è stato il primo della sua "specie" ad usare un'API che sfrutta le gpu per la gui. E' una novità.

Assolutamente no. Lasciando perdere le workstation, il primo home computer / desktop a farne uso dell'hardware della sezione video per accelerare queste operazioni è stato l'Amiga.

Pensa che nelle prime versioni di AmigaOS. avevano usato il Blitter perfino nell'implementazione della WritePixel e della ReadPixel, tanto era l'uso smodato che si faceva dell'hardware custom di cui erano dotati questi computer: poi sono state scritte usando solamente la CPU perché per questo tipo di operazioni era l'unità più adatta.

Per Windows vedi sopra: da anni la GDI è implementata nelle GPU, e le tutte le chiamate vengono smistate a quest'ultima.

Poco importa cosa potevi fare con l'Amiga, al tempo qualsiasi applicativo "intensivo" veniva scritto col compilatore da un lato e l'editor binario dall'altro, non c'era certo il livello di astrazione nello sviluppo raggiunto oggi nè la stessa integrazione, nè le stesse funzionalità nelle interfacce.

Ancora una volta non sono d'accordo. Il problema è che forse tu non conosci abbastanza bene l'Amiga né penso che ci abbia sviluppato degli applicativi.

E' chiaro che ai tempi le primitive implementate in hardware non erano molte (mancava, ad esempio, quella per disegnare ellissi), ma la GUI di AmigaOS è stata sempre molto funzionale e comoda, e col tempo ha subito notevoli migliori, com'è ovviamente avvenuto per ogni s.o...
Poi la Commodore è fallita e chiaramente lo sviluppo s'è arrestato, ma se ancora oggi vai a dare un'occhiata a quello che si riusciva a fare, anche con GUI di terze parti / commerciali (la MUI, ad esempio, è semplicemente impressionante a vederla ancora in funzione), penso che AmigaOS non ha mai avuto nulla da invidiare e ancora oggi potrebbe dire la sua, pur con tutti i limiti di cui sopra.

[cdimauro]

Originariamente inviato da FaveDiFuca
Ciao.
Ti quoto qui perché in altre occasioni hai fatto lo stesso discorso per Longhorn

E quindi?

W la gina sempre

Quoto.

[cdimauro]

x samslaves: grazie per le informazioni. Mi sembra molto interessante, e per questo la sua conoscenza meriterebbe di essere approfondita...

[FaveDiFuca]

Originariamente inviato da cdimauro
E quindi?

Quoto.

E quindi forse la risposta che hai dato non era la più giusta.

[melarido]

Originariamente inviato da cdimauro
La questione è nella modalità con cui ogni s.o./applicazione effettua la gestione, e di conseguenza il redraw, degli oggetti grafici.

Questione che non hai spiegato perchè in origine basata su un concetto errato...
HAI COMUNQUE CITATO UN'ARTICOLO SU OSX 10.1 e stiamo parlando di Panther Se non torni su argomenti attinenti ne deduco che ci stai prendendo per i fondelli...

D'altra parte Windows gestisce il tutto usando la GDI, che da anni ormai è implementata in hardware nelle GPU.

E allora? OpenGL è altrettanto "implementato" e usato per compiti specifici, è la prima volta che viene utilizzato per una gui COMMERCIALE non ESCLUSIVAMENTE destinata ad un ambiente professionale con lo scopo di utilizzare hardware altrimenti relegato a lavorare nella metà della sua esistenza. Se hai altri esempi attinenti da portare bene, sennò non meniamola oltre... per favore!

Assolutamente no. Lasciando perdere le workstation, il primo home computer / desktop a farne uso dell'hardware della sezione video per accelerare queste operazioni è stato l'Amiga.

MA NEMMENO PER SOGNO! Copper e Blitter gestivano gli SPRITE ed in maniera MOLTO primitiva il disegno/filling PIENO degli oggetti 3d, non certo la gui del WORKBENCH. Forse non ricordi ma c'erano polemiche abbastanza aspre sul fatto che il Blitter non veniva usato in moltissimi videogiochi per l'estrema inefficienza e instabilità e veniva per lo più utilizzato esclusivamente per la sua porzione "bidimensionale" al (quasi) pari dell'attuale DirectDraw. Tralascio la tua consueta presunzione di fessaggine dell'interlocutore ma insisto, smettila con questi miscugli, perchè mi sa che sei troppo ben abituato con Borland per ricordare bene com'era "divertente" l'Amiga...

penso che AmigaOS non ha mai avuto nulla da invidiare e ancora oggi potrebbe dire la sua, pur con tutti i limiti di cui sopra.

Opinione più che condivisibile se si accetta nel 2005 la mancanza di una qualche sorta di memoria protetta in un sistema multitasking (!) o più pragmaticamente l'impossibilità in gui di passare da Wordperfect a Deluxe Paint senza riavviare la macchina... sei bravo, sei competente, sei dottore, sai cos'è l'amiga, ma proprio non riesci a restare in TEMA?

[cdimauro]

Originariamente inviato da FaveDiFuca
E quindi forse la risposta che hai dato non era la più giusta.

Non ti seguo: potresti essere più preciso? Cosa avrei detto a proposito di LH in passato?

[cdimauro]

Originariamente inviato da melarido
Questione che non hai spiegato perchè in origine basata su un concetto errato...

In origine si parlava di questo:

Ah dimenticavo: windows, come OS9 e precedenti, non ha un window server nel vero senso della parola. Lo vedi quandro ti si incricca una applicazione e ne sposti la finestra ad esempio.

Sebbene il termine frame buffer non fosse corretto, l'argomento della discussione era ben chiaro, mi sembra. Quindi, fatta questa precisazione, mi dici cosa ci sarebbe di scorretto in quello che ho scritto?

HAI COMUNQUE CITATO UN'ARTICOLO SU OSX 10.1 e stiamo parlando di Panther Se non torni su argomenti attinenti ne deduco che ci stai prendendo per i fondelli...

Vedi sopra: io ricordo perfettamente l'argomento della discussione.

La differenza fra OS X 10.1 e Panther è che quest'ultimo usa le funzionalità OpenGL della GPU per visualizzare la grafica. Ma il window server di cui parlava samslaves si basa sempre sullo stesso principio (windows buffer per ogni finestra).

E allora? OpenGL è altrettanto "implementato" e usato per compiti specifici, è la prima volta che viene utilizzato per una gui COMMERCIALE non ESCLUSIVAMENTE destinata ad un ambiente professionale con lo scopo di utilizzare hardware altrimenti relegato a lavorare nella metà della sua esistenza.

Vorrei che mi spiegassi cosa vuoi dire con questa frase.

Se hai altri esempi attinenti da portare bene, sennò non meniamola oltre... per favore!

Windows e la GDI implementata in hardware da tempo basta come esempio.

MA NEMMENO PER SOGNO! Copper e Blitter gestivano gli SPRITE

Sei completamente fuori strada: gli sprite non li gestiva né il Copper né il Blitter, ma il chip dedicato alla visualizzazione della grafica, Denise.

ed in maniera MOLTO primitiva il disegno/filling PIENO degli oggetti 3d,

Per quanto rozzo, era comunque un'ottima funzionalità che nessun altro hardware consumer offriva a quel tempo.

non certo la gui del WORKBENCH.

Visto che sei così "informato", mi spieghi come faceva il Workbench (per meglio dire Intuition, che era il modulo che si occupa della GUI) a spostare le finestre, far apparire i menù, ecc.? Il lavoro era tutto a carico della CPU? O PER PURO CASO venivano richiamate le funzioni della "graphics.library" per spostare le regioni rettangolari (gestite dalla "layers.library"), che poi smistava il tutto al Blitter?

Forse non ricordi ma c'erano polemiche abbastanza aspre sul fatto che il Blitter non veniva usato in moltissimi videogiochi per l'estrema inefficienza e instabilità e veniva per lo più utilizzato esclusivamente per la sua porzione "bidimensionale" al (quasi) pari dell'attuale DirectDraw.

Quella dell'inefficienza del Blitter e della sua presunta instabilità mi risulta completamente nuova.

Ricordo che ai tempi della conversione de "Il Re Leone" dalle console dell'epoca (SuperNintendo e Megadrive/Genesis) venne fuori che il programmatore che aveva realizzato quel gioco odiava il Blitter, e che aveva preferito usare la CPU per visualizzare la grafica. Infatti i risultati si sono visti: il gioco scattava che era una bellezza, perfino la versione per Amiga1200/4000 (per il chipset AGA).
La verità è che non sapeva come usarlo: forse era troppo abituato a impostare le coordinate x e y per gli sprite hardware delle console (che, quindi, facevano tutto il lavoro).

Comunque, per mi riguarda ho programmato per anni il Blitter e tutto mi puoi dire fuorché che fosse instabile o addirittura inefficiente: un pezzo di silicio in grado di spostare fino a circa 4 MB/s applicandoci delle funzioni logiche, shift e maskeramento ai dati, e per il 1985 era NOTEVOLE.

D'altra parte se fosse stato instabile alla Commodore sarebbero dei pazzi da legare, visto che l'hanno usato per la de/codifica dei dati (nel trackdisk.device, il "driver" che si occupa di gestire i floppy) e che vengono letti/scritti sui floppy.
Immagino già le urla disperate degli utenti che non riescono neppure a fare il boot perché il Blitter fa i capricci...

Tralascio la tua consueta presunzione di fessaggine dell'interlocutore ma insisto, smettila con questi miscugli, perchè mi sa che sei troppo ben abituato con Borland per ricordare bene com'era "divertente" l'Amiga...

Non mettermi in bocca parole che non ho detto. Fino a prova contraria quello che non ricordo nulla di com'era fatto un Amiga e di come funzionava, sei proprio tu.
Io ho sviluppato sia giochi, sfruttando direttamente l'hardware, sia applicazioni, usando chiaramente le API dell'AmigaOS, e ancora oggi ricordo piuttosto bene parecchi dettagli in merito.
E non mi permetterei mai di dire cose che non stanno né in cielo né in terra, come hai fatto tu.

Opinione più che condivisibile se si accetta nel 2005 la mancanza di una qualche sorta di memoria protetta in un sistema multitasking (!)

Non capisco il motivo del (!): non mi sembra che un sistema multitasking debba necessariamente avere la memoria protetta. Sono due cose completamente distinte e separate.

o più pragmaticamente l'impossibilità in gui di passare da Wordperfect a Deluxe Paint senza riavviare la macchina...

Non ho usato WordPerfect, ma con l'Amiga ho usato anche ProWrite, FinalCopy, WordWorth, Cygnus Editor, e altri word processor o editor assieme a Deluxe Paint o altri programmi, senza aver avuto i problemi di cui parli.

sei bravo, sei competente, sei dottore, sai cos'è l'amiga, ma proprio non riesci a restare in TEMA?

Io sì, e vedi sopra: si parlava del sistema di gestione delle finestre.

Un consiglio: evita di "alzare la voce". Finora ho usato un tono cordiale e ho preferito discutere, ma sai che so essere anch'io molto feroce nelle risposte, se voglio.

[Criceto]

Originariamente inviato da cdimauro
OK, hai ragione. Mi riferivo al Window Buffer, non al Frame Buffer.
...
"Mac OS X provides the window server with fast access to pixels by making all windows "buffered." All the pixels of a buffered window are stored in in memory. When one of those pixels is needed in a compositing calculation, the window server simply reads the memory location corresponding to that pixel. It does not have to "ask" the application for the pixel. In fact, an application may be entirely frozen and unresponsive, but its window can still be moved around, hidden, and revealed without any participation from the application. When an application wants to change its window, the changes are all sent through the window server, which updates the window's buffer to reflect the changes."

"But it's the memory usage that's the real killer.
....

Sì è così, ed è grazie a questo approccio che le finestre di OS-X sono così "smooth"... E' una feature di OS-X questa, non un difetto. E' grazie a questo approccio che hanno potuto implementare Exposé. Sempre grazie a questo approccio (credo) hanno potuto mappare le finestre come texture 3D e farle gestire alle scheda grafica per un effetto ancora più fluido. Certo è un approccio un po' "sprecone" di RAM, ma su Panther il buffer delle finestre viene compresso per risparmiare memoria (quell'articolo si riferisce alla 10.1 dove la compressione non era ancora stata implementata) e la memoria virtuale di OS-X funziona bene. Sempre meglio avere un 1/2 giga di Ram, con OS-X, comunque... ma ormai non costa molto.

[melarido]

E' vero ma IMHO è per alcuni un argomento di contestazione assurdo. Anche in windows una finestra di un'applicazione "piantata" può essere mossa per lo schermo, ridimensionata, ridotta e ripristinata. Dipende da diversi fattori, non ultimo ad esempio il fatto che un'app "spalmata" su più processi resti viva nonostante il fallimento di una sua "parte". I benefici di cui l'autore parla e che altri (se non sbaglio samslaves) su questo 3d hanno evidenziato sono legati più che altro all'architettura client/server del sottosistema grafico: liberare l'"applicazione" dalla "visualizzazione" è un vantaggio esattamente come separare i "dati" dalla "presentazione" nella comune programmazione. Il che implica l'adozione di un buffer per le informazioni delle finestre così come in un qualsiasi sottosistema client/server sia l'uno che l'altro possono utilizzare un buffer per un qualsiasi altro motivo. Che i buffer introducano "inefficenza" è una posizione assolutamente soggettiva.

La considerazione che i buffer possono appunto essere compressi (questo dalle mie parti si chiama "efficenza" della gestione della memoria) credo debba essere comunque valutata insieme alla questione del rendering effettuato tramite OpenGL, perchè nel momento in cui una finestra diventa texture e viene "lavorata" su opengl il benedetto buffer in questione non conterrà certo la texture della finestra in questione (come vogliono far credere alcuni), nè interesserà significativamente più di prima il processore. Il che, ripeto, porta ad un utilizzo più ragionevole di acceleratori grafici che nel 90% dei casi resterebbero pressochè inutilizzati. E direi che è questo che spiega la fluidità di applicazioni come exposè, più che il buffering o la struttura client/server in sè. Poteva essere un "killer" in 10.1, di sicuro non lo è oggi.

[melarido]

Originariamente inviato da cdimauro
Un consiglio: evita di "alzare la voce". Finora ho usato un tono cordiale e ho preferito discutere, ma sai che so essere anch'io molto feroce nelle risposte, se voglio.

Bene, continua la tua disquisizione da solo allora. Certi suggerimenti misti a velate minacce appartengono ad alcuni "retaggi culturali" di bassa lega che francamente non condivido e che dovrebbero essere moderati da chi di competenza.

[edoardopost]

Originariamente inviato da cdimauro


Non mettermi in bocca parole che non ho detto. Fino a prova contraria quello che non ricordo nulla di com'era fatto un Amiga e di come funzionava, sei proprio tu.
Io ho sviluppato sia giochi, sfruttando direttamente l'hardware, sia applicazioni, usando chiaramente le API dell'AmigaOS, e ancora oggi ricordo piuttosto bene parecchi dettagli in merito.
E non mi permetterei mai di dire cose che non stanno né in cielo né in terra, come hai fatto tu.

Un consiglio: evita di "alzare la voce". Finora ho usato un tono cordiale e ho preferito discutere, ma sai che so essere anch'io molto feroce nelle risposte, se voglio.

Minchia dotto'...
Certo che 'ste questioni vi stanno VERAMENTE a cuore eh ?


Allora, dicevamo, Macworld Expo 2005 ?

[DioBrando]

Originariamente inviato da melarido
Bene, continua la tua disquisizione da solo allora. Certi suggerimenti misti a velate minacce appartengono ad alcuni "retaggi culturali" di bassa lega che francamente non condivido e che dovrebbero essere moderati da chi di competenza.

scusa eh n per fare l'avvocato del Diavolo, ma se butti lì msg tipo dottore ecc alludendo ( IMHo maliziosamente) alla preparazione dell'interlocutore non puoi evitare che la risposta sia altrettanto acida.

Se decidi di impostare la conversazione su di un certo tono devi essere anche conscio che l'altro potrebbe non "mandartele a dire"; e la minaccia cmq era solo verbale, nel senso che nello scontro tra opinioni diverse avrebbe cercato tramite info tecniche ( sempre + accurate) di smontarti; mica esce di casa prende la lupara e ti bussa alla porta



Cmq Giava&Pis per tutti

n sò se era stato postato in precedenza, cmq lascio l'url del sito

link

Saluti

[cdimauro]

Originariamente inviato da Criceto
Sì è così, ed è grazie a questo approccio che le finestre di OS-X sono così "smooth"... E' una feature di OS-X questa, non un difetto.

"Smooth" lo sono anche le finestre di Windows, pur avendo un sistema di gestione diverso. D'altra parte, come ho già detto, Windows utilizza già le GPU per scaricare loro la maggior parte del lavoro.
L'unico inconveniente si verifica quando un'applicazione non risponde: qui chiaramente OS X la fa da padrone, perché permette di visualizzarne comunque il contenuto. Ma non so quanto possa essere importante poterlo fare, visto lo stato in cui versa l'applicazione.

E' grazie a questo approccio che hanno potuto implementare Exposé. Sempre grazie a questo approccio (credo) hanno potuto mappare le finestre come texture 3D e farle gestire alle scheda grafica per un effetto ancora più fluido.

Esattamente: una volta che il buffer è già disponibile in memoria, lo si può sfruttare per fare quanto hai scritto.

Certo è un approccio un po' "sprecone" di RAM, ma su Panther il buffer delle finestre viene compresso per risparmiare memoria (quell'articolo si riferisce alla 10.1 dove la compressione non era ancora stata implementata)

Sì, ma la de/compressione ha anche un costo in termini di CPU e ulteriore frammentazione della memoria; inoltre una finestra che ha il buffer compresso non è immediatamente disponibile per le operazioni di cui sopra.

e la memoria virtuale di OS-X funziona bene. Sempre meglio avere un 1/2 giga di Ram, con OS-X, comunque... ma ormai non costa molto.

Infatti. Ma all'inizio OS X si è rivelato pesantuccio per la macchine dell'epoca.

Comunque, come ho già detto, ogni sistema ha i suoi pro e i suoi contro. Windows e Mac OS Classic permettono di avere e mantenere un elevato numero di finestre anche su sistemi dotati di poca memoria. Inoltre Windows fa già uso da tempo della GPU per implementare le funzioni della GDI, per cui il carico sulla CPU risulta comunque molto più ridotto.

[cdimauro]

Originariamente inviato da melarido
E' vero ma IMHO è per alcuni un argomento di contestazione assurdo.

Il maggior consumo della memoria non mi sembra tanto assurdo.

Anche in windows una finestra di un'applicazione "piantata" può essere mossa per lo schermo, ridimensionata, ridotta e ripristinata. Dipende da diversi fattori, non ultimo ad esempio il fatto che un'app "spalmata" su più processi resti viva nonostante il fallimento di una sua "parte".

Esattamente. Però non ne vedi più il contenuto, appunto, mentre con OS X sì.

I benefici di cui l'autore parla e che altri (se non sbaglio samslaves) su questo 3d hanno evidenziato sono legati più che altro all'architettura client/server del sottosistema grafico: liberare l'"applicazione" dalla "visualizzazione" è un vantaggio esattamente come separare i "dati" dalla "presentazione" nella comune programmazione. Il che implica l'adozione di un buffer per le informazioni delle finestre così come in un qualsiasi sottosistema client/server sia l'uno che l'altro possono utilizzare un buffer per un qualsiasi altro motivo.

Mi spiace, ma non è affatto è un'implicazione diretta. Se è vero che un'applicazione deve provvedere al redraw, è anche vero che tutte le API della GDI che usa sono implementate in hardware, per cui il consumo di risorse (CPU) sarà estremamente ridotto.

Che i buffer introducano "inefficenza" è una posizione assolutamente soggettiva.

Quindi per te il maggior consumo di memoria non è rappresenta un'inefficienza?

La considerazione che i buffer possono appunto essere compressi (questo dalle mie parti si chiama "efficenza" della gestione della memoria)

Si chiama anche spreco di potenza di calcolo della CPU.

Invece in Windows e MacOS Classic non sprechi la CPU per queste operazioni, e il consumo di memoria è enormemente ridotto: quindi sono sicuramente più efficienti (Windows particolarmente, visto che sfrutta la GDI implementata in hardware nelle schede video).

credo debba essere comunque valutata insieme alla questione del rendering effettuato tramite OpenGL, perchè nel momento in cui una finestra diventa texture e viene "lavorata" su opengl il benedetto buffer in questione non conterrà certo la texture della finestra in questione (come vogliono far credere alcuni), nè interesserà significativamente più di prima il processore. Il che, ripeto, porta ad un utilizzo più ragionevole di acceleratori grafici che nel 90% dei casi resterebbero pressochè inutilizzati.

Vedi sopra: qual è la differenza fra utilizzare la GDI hardware delle GPU anziché le funzionalità OpenGL? Dal punto di vista dell'applicazione nessuna: viene comunque scaricato il lavoro sulla GPU: chi se ne frega se poi sarà una sezione della GPU piuttosto che un'altra a farsene carico?

E direi che è questo che spiega la fluidità di applicazioni come exposè, più che il buffering o la struttura client/server in sè.

Non è così. Come ha detto Criceto, è il fatto di avere il buffer col contenuto della finestra immediatamente disponibile (e da passare alla GPU) che avvantaggia l'esecuzione di Exposé.

Poteva essere un "killer" in 10.1, di sicuro non lo è oggi.

La situazione è migliorata, ma il consumo della memoria è rimasto lo stesso.

[cdimauro]

Originariamente inviato da melarido
Bene, continua la tua disquisizione da solo allora. Certi suggerimenti misti a velate minacce appartengono ad alcuni "retaggi culturali" di bassa lega che francamente non condivido e che dovrebbero essere moderati da chi di competenza.

DioBrando ha già chiarito perfettamente cosa volevo dire. D'altra parte è sufficiente seguire il thread con attenzione per non perdere il filo e capire il perché di alcune parole...

Inoltre non accetto sermoni da chi passa più tempo a provocare che ad argomentare le proprie tesi:

Se non torni su argomenti attinenti ne deduco che ci stai prendendo per i fondelli...
Se hai altri esempi attinenti da portare bene, sennò non meniamola oltre... per favore!
Tralascio la tua consueta presunzione di fessaggine dell'interlocutore ma insisto, smettila con questi miscugli, perchè mi sa che sei troppo ben abituato con Borland per ricordare bene com'era "divertente" l'Amiga...
sei bravo, sei competente, sei dottore, sai cos'è l'amiga, ma proprio non riesci a restare in TEMA?

Per non parlare delle parti che hai scritto interamente in maiuscolo e con un tono decisamente duro.

Quindi se c'è qualcuno che si deve moderare qui sei tu.

D'altra parte qualche giorno fa in questo stesso thread t'avevo scritto questo:

Ma non c'eravamo lasciati cordialmente dopo d'ultima (infuocata) discussione?

Perché avevi già iniziato a scadere sul personale, mentre io volevo continuare la discussione sul piano tecnico.

Ma evidentemente è più forte di te: il tuo spirito da troll non riesce a starsene fermo, se non per un breve periodo. Poi deve per forza liberarsi e sfogarsi.

Per quanto mi riguarda, e come ti ho già anticipato, se non torni sui binari giusti la prossima volta i miei commenti non saranno così pacati come lo sono stati finora: saranno mazzate. Verbali come ha giustamente sottolineato DioBrando. D'altra parte sei tu stesso che te le stai cercando.

Invece di perdere tempo con delle stupide provocazioni, cerca di documentarti invece di uscirtene fuori con delle assurdità come "Copper e Blitter gestivano gli SPRITE ed in maniera MOLTO primitiva il disegno/filling PIENO degli oggetti 3d, non certo la gui del WORKBENCH": può far presa soltanto con chi, come te, ignora completamente come funzionasse sia l'hardware sia il s.o. dell'Amiga...

[cdimauro]

Originariamente inviato da edoardopost
Minchia dotto'...
Certo che 'ste questioni vi stanno VERAMENTE a cuore eh ?

Certo che mi stanno a cuore: con l'Amiga ho passato una buona parte della mia vita, e non l'ho fatto certo passando il tempo inserendo dischetti e attaccandomi al joystick, come probabilmente ha fatto melarido, visto che ha dimostrato di non avere la benché minima conoscenza né dell'hardware né del s.o. dell'Amiga.

Erano tempi in cui l'"Hardware Manual" e i "ROM Kernel Manuals" erano la bibbia per chi programmava l'hardware direttamente o utilizzava le API del s.o...

Erano tempi in cui ci si sbatteva la testa per risparmiare anche un ciclo di clock, visto l'hardware limitato che era disponibile. Erano tempi in cui si fagocitavano avidamente le pagine di quel manuale e facendo prove su prove per cercare di spremerlo come un limone.

E mi dà veramente fastidio che uno come lui, che di tutto ciò NON CONOSCE NULLA, si permetta criticare e d'inventarsi addirittura delle cose di sana pianta (come l'instabilità e l'inefficienza del Blitter).
Qualunque programmatore Amiga rimarrebbe indignato a sentire tutte queste falsità, e Jay Miner si starà già ribaltando nella tomba...