2010-01-27 11 views
5

Se sto scrivendo codice di disegno in Graphics Core su Mac OS X o iPhone OS, è possibile impostare il colore di riempimento attivo rosso chiamando:È prevista una penalità per la miscelazione degli spazi colore? (Core Graphics)

CGContextSetRGBFillColor(context, 1.0, 0.0, 0.0, 1.0); // RGB(1,0,0) 

Se voglio grigio al 50%, ho potuto chiamata:

CGContextSetRGBFillColor(context, 0.5, 0.5, 0.5, 1.0); // RGB(0.5,0.5,0.5) 

Ma per sfumature di grigio si sta tentando di fare una linea più breve e chiamare:

CGContextSetGrayFillColor(context, 0.5, 1.0); 

Carn er, questa funzione NON sta semplicemente chiamando il metodo RGB con il valore di intensità copiato tre volte; invece sta cambiando lo spazio colore del contesto da DeviceRGB a DeviceGray. La prossima chiamata a un metodo RGB lo cambierà.

Sono curioso di sapere:

  • Qual è la pena per la commutazione spazi di colore?
  • È prevista una penalità per il disegno quando lo spazio colore del contesto non corrisponde allo spazio colore nativo del dispositivo? (cioè, disegno in DeviceGray contro DeviceRGB)

Sto chiedendo per curiosità tecnica, non un desiderio di ottimizzare prematuramente, quindi per favore mantieni le tue ammonizioni al minimo, per favore.

+1

Non ho idea se sia più veloce, ma non potresti testarlo costruendo un progetto di test che verifica questo? Una corsa eseguiva il test del riempimento utilizzando sempre lo stesso spazio colore, mentre l'altro passava da uno spazio colore all'altro. Direi che se c'è una penalità, è nel convertire i valori del colore dallo spazio colore allo spazio colore della bitmap, ma la differenza sarebbe trascurabile tra i test. – lucius

+0

Sì, a questo punto ho intenzione di scrivere un codice di prova quando ho tempo. Stavo aspettando di ottenere un badge Tumbleweed, ma sembra che la mia domanda non sia abbastanza interessante. – benzado

risposta

1

Ho utilizzato entrambi in modo estensivo in modo simile e non ho notato penalità in termini di prestazioni.

+0

Immagino che qualsiasi differenza nelle prestazioni sia inferiore alla soglia di "notificazione". – benzado

+0

Sì. Tuttavia, il modo corretto è quello di eseguire benchmark se si pensa che potrebbe esserci una penalizzazione delle prestazioni.Per esperienza, posso dirvi che solo i metodi/proprietà che disegnano direttamente sullo schermo (o influenzano il disegno) possono avere una penalità, per es. adjustsFontSizeToFitWidth. Questo potrebbe non essere sempre evidente. –

3

Concettualmente, c'è una penalità, ma in pratica è così minuscolo da essere irrilevante; la conversione (ad esempio una sfumatura di grigio in una tripletta RGB (più alpha) è aritmetica banale anche con uno spazio colore personalizzato.

spazi colore do hanno una penalità quando si disegna le immagini, tuttavia, poiché si tratta di più di una semplice operazione di conversione. Ogni pixel deve essere convertito, e mentre ci sono ottimizzazioni che possono essere fatte qui (ad es. CLUT, Tabelle di ricerca del colore, sono utili se l'immagine di origine utilizza colori indicizzati) non tendono ad essere utili in situazioni in cui si trovano anche Codice al quarzo

Si dice che si aspetta CGContextSetGrayFillColor() per modificare lo spazio colore del contesto grafico, ma in realtà non è questo il caso. In questo modo è necessario convertire i contenuti di quel contesto grafico in modo che corrispondano al nuovo spazio cromatico del contesto. Poiché è molto più economico e semplice convertire il colore anziché i buffer del contesto (ad esempio rendendo CGContextSetGrayFillColor() un involucro sotto le copertine intorno a CGContextSetRGBFillColor()), tale spesa sarà evitata in qualsiasi implementazione ragionevole.

+0

La documentazione [afferma chiaramente] (http://developer.apple.com/iphone/library/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextSetRGBFillColor) che il 'CGContextSet * Le funzioni colore() 'cambiano lo spazio colore del contesto. Ma non penso che sia lo stesso che cambiare lo spazio colore del buffer in cui stai disegnando, però. – benzado

+1

No, dice che impostano gli spazi colore * fill * o * stroke * - gli spazi colore in cui i valori 'CGFloat' passati formano una coordinata di colore. Significa solo che, quando fornisci R, G, B, A o qualsiasi altro valore tu abbia passato, vengono interpretati correttamente. Lo spazio colore del contesto, se può essere pensato come se avesse uno, corrisponde sempre allo spazio colore della destinazione; avere i due non corrisponde sarebbe privo di senso. :) Vedere i documenti per 'CGContextSetStrokeColorSpace()' e 'CGContextSetFillColorSpace()' - queste funzioni finiscono per completare uno di questi & 'CGContextSetFillColor()'. –

+1

(o attorno a 'CGContextSetStrokeColor()' Eseguito fuori dalla stanza.) –

Problemi correlati