Newsgroup: it.comp.os.dibattiti
Titolo: Re: [OT][FLAME] Menomale che Arthur ha copiato Cairo

 non avesse fatto il test in maniera corretta).
Beh se è vero buono a sapersi! Perché flame?
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 non avesse fatto il test in maniera corretta).
ahahah.  ah.
* non si sa come sia stato fatto il benchmark;
* non ci sono intervalli di confidenza o deviazioni statistiche;
* diavolo, non ci sono nemmeno il numero di iterazioni fatte;
* rusin ammette candidamente di aver usato cairo stable contro qt
unstable;
* l'aggeggio della qt è tutto ad algebra con interi mentre
cairo no; è da due mesi che stiamo tentando (parlo della ditta per cui
lavoro) di convincere carl a passare a un'algebra ad interi,
soprattutto per gli ambienti embedded[1], e adesso pare che ci stia
dando retta.
per altro, però, cairo è - come API - teso a non inchiappettare il
programmatore cambiando tra minor release come la qt è nota fare.
+++
[1] è noto ormai anche ai sassi che chi lavora su piattaforme embedded o
rimane alle gtk+ 2.6.0-pre-cairo oppure si mantiene due tree paralleli
de-cairo-izzati di gtk+ e pango; personalmente la ritengo una vaccata:
se nokia e altre aziende si dannassero la metà del tempo e del personale
a migliorare cairo invece di mantere un tree parallelo e diventare scemi
nel farlo, probabilmente cairo sarebbe più veloce dell'aggeggio delle qt.
ciao,
 Emmanuele.

 dando retta.
dimenticavo: il benchmark è tutto teso a dimostrare che il tesselator di
qt unstable è più veloce del tesselator di cairo stable - cosa che carl
stesso ha ammesso, infatti si è scritto un nuovo tesselator.  poi il
benchmark dimostra che uno stencil buffer è più veloce di un tesselator
- e bella forza; peccato che nel mondo reale è il tesselator ad essere
usato (svg, testo) e non lo stencil buffer.
+++
poi, intendiamoci, cairo è lento. lento, lento, lento. specie su ARM e
ferraglia senza una FPU. sicuramente, però, non serve un benchmark del
genere per dimostrarlo.
ciao,
 Emmanuele.

 Ma si son dimenticati di imitare le performance :P
a quando un tessellator scritto da te? 
cosi' magari ce la ridiamo anche noi per bene :)
ti saluto
-- 
Gian Mario Tagliaretti

 checkout, fai un po' te.
con "cairo git" non si intende nulla.  non è come dire HEAD di un
progetto su CVS, o trunk su SVN.  git, essendo un SCM distribuito, ha
tree per ogni branch; alcuni non sono nemmeno state messe sul
repository centrale, dato che si può fare un commit locale e dire ad
altri sviluppatori di fare un pull.
quindi dire "cairo git" significa tutto e non significa niente.
il resto di quanto ho scritto è sufficientemente inopponibile: il
benchmark di rusin è scritto per testare un caso limite (abbastanza
patologico) e far vedere che il nuovo codice della trolltech è forte in
quel caso.  il benchmark fallisce nel darci un motivo per capire
*perché* arthur sia più veloce o, in alternativa, perché cairo sia più
lento (dato che ci vengono dati solamente i data point e nient'altro
sulla struttura del benchmark stesso).
il take di carl, per chi vuole leggerlo, è qui:
http://mail.gnome.org/archives/performance-list/2006-October/msg00053.html
http://mail.gnome.org/archives/performance-list/2006-October/msg00054.html
ciao,
 Emmanuele.

 il codice (e che anzi glielo aveva passato il giorno prima)
carl ha ricevuto i data point - gli stessi linkati sul blog con i bei
grafici; il codice del programma usato nel benchmark non è stato
pubblicato - e rusin dice che non lo pubblicherà nel blog che citi in
fondo.
ma il programmino che viene usato nel benchmark non è il benchmark;
servono il numero di iterazioni e un po' più di informazioni di:
| The test is composed of rendering three complex polygons. The first
| one is a text path, the second is a small polygon with a large amount
| of vertices that fall on the same scanline and the third one is a huge
| polygon with about 100000 vertices.
che testo è? quanto è "large amount" e quanto è "small"? quanti sono i
vertici che producono segmenti intersecanti, e quante intersezioni sono
presenti nel "huge polygon"?
il test *non* è riproducibile - che è l'unica cosa utile di un benchmark
per fare il profiling di una libreria; e se non è riproducibile allora
non serve a niente.
e personalmente mi spiace molto leggere queste cose, perché zack ha
probabilmente ragione e arthur potrebbe essere molto interessante per
rendere cairo più veloce.
ciao,
 Emmanuele.