La pregunta original ...............................................

Si eres un usuario avanzado de drawRect, sabrás que, por supuesto, drawRect no se ejecutará hasta que "todo el procesamiento haya finalizado".

setNeedsDisplay marca una vista como invalidada y el sistema operativo, y básicamente espera hasta que se complete todo el procesamiento. Esto puede ser irritante en la situación común en la que desea tener:

un controlador de vista 1inicia alguna función 2que incrementalmente 3crea una obra de arte cada vez más complicada y 4en cada paso, establece NeedsDisplay (¡incorrecto!) 5hasta que todo el trabajo esté hecho 6

Por supuesto, cuando haces lo anterior 1-6, todo lo que sucede es que se ejecuta drawRectpor una sola vez después del paso 6.

Su objetivo es que la vista se actualice en el punto 5. ¿Qué hacer?

Solución a la pregunta original ............................................. .

En una palabra, puedes(Un fondo la pintura grande, y llame al primer plano para actualizaciones de UI o(B) posiblemente controvertido Se sugieren cuatro métodos "inmediatos" que no utilizan un proceso en segundo plano. Para el resultado de lo que funciona, ejecute el programa de demostración. Tiene # define para los cinco métodos.

Solución alternativa verdaderamente sorprendente introducida por Tom Swift ..................

Tom Swift ha explicado la increíble idea de simplementemanipulando el ciclo de ejecución. Así es como se activa el ciclo de ejecución:

[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate: [NSDate date]];

Esta es una pieza de ingeniería realmente sorprendente. Por supuesto, uno debe ser extremadamente cuidadoso al manipular el ciclo de ejecución y, como muchos señalaron, este enfoque es estrictamente para expertos.

El extraño problema que surge ............................................. .

Aunque algunos de los métodos funcionan, en realidad no "funcionan" porque hay un extraño artefacto de desaceleración progresiva que verá claramente en la demostración.

Desplácese hasta la 'respuesta' que pegué a continuación, que muestra la salida de la consola: puede ver cómo se ralentiza progresivamente.

Aquí está la nueva pregunta SO:
Misterioso problema de "desaceleración progresiva" en run loop / drawRect

Aquí está V2 de la aplicación de demostración ...
http://www.fileswap.com/dl/p8lU3gAi/stepwiseDrawingV2.zip.html

Verá que prueba los cinco métodos,

#ifdef TOMSWIFTMETHOD
 [self setNeedsDisplay];
 [[NSRunLoop currentRunLoop]
      runMode:NSDefaultRunLoopMode beforeDate:[NSDate date]];
#endif
#ifdef HOTPAW
 [self setNeedsDisplay];
 [CATransaction flush];
#endif
#ifdef LLOYDMETHOD
 [CATransaction begin];
 [self setNeedsDisplay];
 [CATransaction commit];
#endif
#ifdef DDLONG
 [self setNeedsDisplay];
 [[self layer] displayIfNeeded];
#endif
#ifdef BACKGROUNDMETHOD
 // here, the painting is being done in the bg, we have been
 // called here in the foreground to inval
 [self setNeedsDisplay];
#endif

Puedes ver por ti mismo qué métodos funcionan y cuáles no.

Puedes ver el extraño "progresivo-desaceleración". ¿Por que sucede?

Como puede ver con el controvertido método TOMSWIFT, en realidad no hay ningún problema con la capacidad de respuesta. toque para obtener respuesta en cualquier momento. (pero sigue siendo el extraño problema de "progresivo-desaceleración")

Entonces, lo abrumador es esta extraña "desaceleración progresiva": en cada iteración, por razones desconocidas, el tiempo que lleva un bucle fallece. Tenga en cuenta que esto se aplica tanto a hacerlo "correctamente" (búsqueda de fondo) como al uso de uno de los métodos 'inmediatos'.

Soluciones prácticas ........................

Para cualquiera que lea en el futuro, si realmente no puede hacer que esto funcione en el código de producción debido a la "desaceleración progresiva misteriosa" ... Felz y Void han presentado soluciones sorprendentes en la otra pregunta específica, espero que ayude.