4to Jueves Sensual de Programación(Milton Dev Log 4)

Milton Dev Log 4

Así es, chavos. Es hora de otro ‪#‎JuevesSensualDeProgramación‬

Milton Dev Log 4 — El Algoritmo de Edd y otras cosas

Yayyyy!!!

¿Que dice la gente?

  • En este momento estás en la TV del trabajo.
  • I Love #JuevesSensualDeProgramación

Sergio: que pena pero que chido

  • Awesome! Se ve super interesante lo de los jobs, y los cachés que mencionas. Go Sergio, Go!
  • Chido! Me parece interesante donde exploras posibles opciones para dividir la imagen en trabajos, y mencionas dividir la imagen en áreas equitativas.
    Entiendo que por simplicidad esa es la manera mas directa de hacerlo.
    Pero no se si sea un assumption que pueda pesar en el perceived performance, porque dependiendo de como yo distribuya mis trazos, puede ser que la manera en que tu distribuyas los jobs, haga que un(os) thread(s) esten casi siempre procesando áreas relativamente sencillas o en blanco, mientras otros threads se tarden mas porque le tocaron casi todos los jobs “pesados”.
    Al final, el usar un queue de trabajos puede aliviar parcialmente este concern, pero mi punto es que no se si pueda eso tener un efecto negativo en la percepción del usuario de como se está procesando la imagen.Puede que esto caiga en micro optimización la cual no creo tenga cabida en este momento o algo con lo que tendremos que vivir.
    Pero se me hizo importante notarlo ya que (al menos en dibujos sencillos) siempre habrá una porción que en algunos casos pueda ser significativa del total de la imagen que “este en blanco” (que no tenga trazos)

Sergio: Qué opinan de compilar con Emscripten a asm.js y hacer que Milton sea una Web App? Tiene muchas (des-)ventajas. Distribución automática. SaaS da más dinero. Menos fricción del departamento de IT para compañías que quieran usarlo. Desventajas: Nada de low-level goodness. Más lento en general (aunque asm.js sólo se va a poner mejor)

Estaba pensando que saldría un buen ‘load balancing’ naturalmente si (como tú dices) hago que cada thread agarre el primer trabajo de una cola. Supestamente así cada thread estaría ~100% ocupada hasta que no hubiera más trabajos, independientemente de qué tan complicado sea cada trabajo individual. O sea, si hay trabajos vacíos, salen de la cola inmediatamente y el primer thread disponible agarra el siguiente.
Otra ventaja de dividir la pantalla en un grid: Cada trabajo no tiene dependencias de datos, no tengo que hacer locks.

No se… Aún así llegan a la mente otros problemas: Efectos raster como Blurs son un pedote, porque son basicamente un mutex. No puedes aplicar un Blur hasta que hayas rasterizado todos los ‘chunks’ que van a ser afectados.

A ver cómo va saliendo… Muchas gracias por el ‘wall of text’. Sé que toman tiempo de escribir pero son buena ayuda / motivación

  • No creo que siendo Web App logres a lo que quieres llegar con Milton.>dat fast infinite anti-aliasHay web apps que lo hacen bastante bien (pixlr, mondrian, janvas).Por otro lado… si es posible lograrlo, monetizarlo será muuucho más fácil.

Sergio: Ya has visto demos de asm.js? Es un subset tipado de JS que se compila a código máquina. Unreal tenía un demo muy impresionante.
No conocía esas web apps Algo muy parecido es lo que tengo en mente. Igual y les puedo mandar un mail amigable. No soy competencia directa y ellos ya pasaron por las etapas de conseguir usuarios y demás…
No pierdo mucho con intentar compilar lo que tengo a JS… El mayor problema que le veo es que puede que no haya buen soporte de Wacom para la web.

  • Creo que tu mismo te respondes la pregunta sobre hacerlo web en tu primer vídeo. El punto es evitar toda la latencia posible y creo que en web, por más rápido que corra no va a correr igual. Dejando de lado lo demás de la parte técnica que creo que va a tener muchos problemas que no podemos prever y que tendrás que resolver en su momento, mi problema es la usabilidad. En mi opinión las aplicaciones web nunca funcionan tan bien como deberían. Que la interfaz de tu app corra dentro de otra interfaz hace que sea medio molesto usarlas. A veces sólo deciden no cargar bien y tienes que relodear. A veces el explorador colapsa por motivos desconocidos. A veces tardan años en cargar. Esto no suena como un súper pedo, pero cada pequeño detalle de usabilidad de un programa contribuye a tener una experiencia positiva o negativa al usar la app y en web hay muchos factores que tu no con trolas.
  • C la ++ tucun tsssssss

Sergio: Roberto Ahorita estoy muy contento porque tengo mi latencia mínima jalando sin usar threads y con anti-alias y sin errores. Puedo tomar un golpe de 2x sin sufrir demasiado. Eso es más o menos lo que esperaría de asm.js
Los problemas de usabilidad… Sí… tienes razón. Y encima de eso, no tengo experiencia manteniendo webapps. Por otro lado, todo lo que uso de día a día que no sea mi editor / debugger está en la web. Github, Trello, Gmail… Mi diario es una webapp… Mi televisión es una webapp. Leo pdf’s en chrome. Hay muchas desventajas pero también hay muchas ventajas. No me estoy casando con ninguna… Sigo pensando que hacerla como app móvil es muy buena idea también. Hay que ver…

Para ver la serie completa de Jueves Sensual de Programación da click aquí.

#JuevesSensualDeProgramación‬