Archivo de la categoría ‘Web’

Google I/O 2013: Resumen del Keynote, Parte 2

Continuando con el resumen sobre el KeyNote:

 

Chrome

En esta ocasión disfruté bastante de la presentación que realizó Linus Upson (Ingeniero de Chrome) sobre Chrome, o más concretamente sobre la web en general. Esperaba una presentación monotemática de Chrome, y en vez de eso, Linus habló en gran parte de la Web en general, por supuesto Chrome como pivote. Igualmente, me resultó un gesto de buena fe (teniendo en cuenta la competitividad insana que vemos a día de hoy en cuanto a tecnología se refiere) cuando no pudo dejar de nombrar la gran labor de los chicos de Mozilla en cuanto a la creación de ASM.js, un subconjundo JavaScript que es capaz de «super optimizar» JavaScript el código JavaScript procedente principalmente de compiladores como Emscripten, que permiten compilar código escrito en C/C++ a JS. A modo de prueba en la próxima comparativa se verá un poco mejor que es esto y como repercute en el navegador, pero pensar en poder ejecutar en el navegador juegos o aplicaciones de escritorio a una velocidad bastante aceptable, y prueba de ello tenemos ya algunas demos realizadas con Unreal Engine que son sorprendentes.

 

-JavaScript:

Lo primero que se hizo hincapié, fue la gran evolución de los navegadores en cuanto a JS, incrementándose en un 24% en el caso de los equipos de sobremesa, un 57% en dispositivos portátiles, y con tecnologías como Odin de Mozilla (el motor que usa asm.js) se ha llegado a lograr un rendimiento de 2.4 veces superior, este último dato de nuevo, SOLO en aquellas aplicaciones/juegos determinados por supuesto.La necesidad de la evolución de los navegadores frente a JS es una cuestión sencilla, cada vez más el navegador es la puerta al software, el cual (las aplicaciones web) son cada vez más sofisticadas, complejas… y por tanto requieren de un mayor tiempo de respuesta. Son ya muchos años los que se siguen hablando de HTML5, y como ya he dicho una y otra vez, es algo que requiere años y años, no se verá nunca un cambio radical en el modo de concebir la web, será gradual… ya lo estamos viviendo de echo, pero muy poco a poco.

Para ver un ejemplo de todo ello, quien quiera puede ver la demo de ejemplo de Unreal Engine

Unreal Engine

111fps en ese frame en 1080p. Evidentemente si se corriese la misma demo en una aplicación de escritorio, el resultado sería bastante superior, pero podemos verlo por el lado contrario, ejecutado sin las nuevas tecnologías iría infinitamente más lento.

 

Con motivo del 20 aniversario (que se celebró el 30 de Abril de este año) de la web, o más exactamente de la primera web creada en el mundo, Google creó un emotivo vídeo de «como empezó todo» y «donde estamos ahora». Quizás para muchos de los lectores nacieron o crecieron con la web, pero para muchos otros han ido viviendo día a día como fueron cambiando las cosas. Por desgracia no he podido encontrar el vídeo suelto, así que enlazo a la sección de tiempo exacta donde comienza. Estoy seguro que a los nostálgicos les encantará. Poro otro lado, para quien lo desee, el CERN ha creado un pequeño site para esas primeras cosas que aparecieron entonces: AQUI, y por supuesto la primera URL creada en el mundo: AQUI

 

-WebP:

Se hizo la presentación de WebP por otro lado, que no es sino un formato «nuevo» de imagen, un algoritmo de compresión como pueda serlo JPG, PNG, GIF, PSD… y tantos otros. Es un proyecto más de Google que lleva tiempo cociéndose, pero como otras cosas, se veía que quedaría olvidado en el cajón, a fin de cuenta es muy muy complicado cambiar los hábitos de las personas, y decirles que jpg es un formato/compresión muy muy antigua y que existen alternativas mucho mejores, pues es complicado. El mejor ejemplo de ello lo tenéis con MP3, es de lejos el codec de audio más extendido en el mundo, y en cambio hace ya muchos muchos años tenemos otros como AAC o incluso OPUS que son mucho mejores, es decir conservan más calidad en el mismo espacio o mantienen la misma calidad en menos espacio. En cambio no se usan por culpa del usuario de a píe, que normalmente no saben siquiera que existen.

Bien, pero si realmente Google quiere y espera que WebP pueda tener una oportunidad… ¿que ofrece? Teóricamente hablando por supuesto, una reducción de tamaño incluso de un 30% con respecto a JPG. Pensar un poco en esto. La mayoría del tráfico en cualquier site son las imágenes. Si redujésemos de un plumazo TODAS las imágenes de la web un 30%, esto resultaría en un impacto dramático a la hora de ver las webs, desde el tiempo de carga de las páginas, el ahorro ingente de dinero en ancho de banda y almacenaje necesario, una mayor velocidad a la hora de cargar las webs… y eso solo aplicando esa reducción de peso. Por supuesto es algo teórico, pero aun cuando se alcanzasen tasas del 20% de media respecto a JPG, resulta tan atractivo que NADIE sería capaz de no usarlo.

Además de la mayor compresión, que parece evidente sería el mayor punto fuerte, WebP cubriría también las carencias que han hecho que a día de hoy convivan tantos formatos de imágenes. Por ejemplo, la mayor lacra de JPG, un canal Alpha, es decir, transparencia. Para un fotógrafo puede parecer que aplicar una transparencia es absurdo, pero para la web esto es imprescindible, incluso para la edición fotográfica, aunque se usa sin ser consciente de ello la mayoría. Casi cualquier web del mundo usa en su gran medida imágenes PNG para el contenido, entre otras cosas porque fundamentalmente permite transparencias.

Sin entrar en demasiado detalle del resto de las mejoras que entraña webP, por supuesto soporta compresión sin pérdida, metadatos, perfiles de color e incluso animaciones al estilo GIF.

En mis pruebas personales, posiblemente requeriría otro artículo completo para discutir los pasos y métricas, encontré que es cierto qeu webP es superior en cuanto a calidad se refiere a JPG o PNG, de echo bastante superior. Es como todo, yo no me creo o dejo de creer nada porque Google o cualquier otra compañía lo digo, prefiero verlo con mis propios ojos y judgarlo. En mis test, es cierto que cuando la compresión era baja (gran tamaño de archivo) la calidad de la imagen resultante era muy parecida, como cabría esperar, pero a medida que se va aumentando la compresión de la imagen, vemos como webP es realmente una apuesta ahora mismo insuperable, sobre todo para la web. No podría hablar de que porcentaje mejor, pero a simple ojo es evidente. Un sencillo ejemplo:

webp
La imagen original era de 22 megapixel,  y de ella se crearon dos versiones con la premisa de que tenían que ocupar 256KB (sin redimensionar). Evidentemente la imagen mostrada no tiene calidad suficiente para hacer una buena comparación, pero podemos ver perfectamente como webP es capaz de mantener bastante bien la calidad (visualmente hablando), mientras que JPG la destruye. Ambos archivos terminaron con un tamaño similar, rondando los 256KB, la original sin compresión, algo más de 63MB. Como digo, podría decirse mucho más sobre ello, pero requeriría un artículo solo para ello.

 

-VP9 y OPUS:

Un vídeo no es más que una superposición de imágenes a una tasa suficientemente alta como para tener la percepción de movimiento. Al igual que Google habló de webP para la compresión de imágenes como un buen sustituto, también presentó el nuevo codificador de vídeo que están ultimando, VP9.

Recordemos que Google compró no hace demasiado toda la tecnología VP8, y con él dio el pistoletazo a webM, para combatir el problema existente de la reproducción de vídeos en la web. Recordemos que el estándar de HTML5 para la reproducción de vídeo, no establece que codecs serán en los que tenga que estar el vídeo, y eso hace que cada navegador implemente el que el crea. De esto se ha hablado mucho. De nuevo la idea es simple, como obtener la mayor calidad de imagen con el menor tamaño posible, al igual que sucede con las imágenes. Hasta la fecha, por mucho que digan algunos H264 era el claro vencedor, honestamente era muy superior que el codec VP8.

WebM apareció como la solución al vídeo en la web, para ser usado como estándar por todos los navegadores. Aunque h264 es superior a VP8, el problema que tiene es que está fuertemente patentado, y cualquier distribuidor de contenidos tiene que pagar a la MPEG LA los royalties correspondientes. Estos Royalties pueden alcanzar millones de euros!! Este fue fundamentalmente el motivo por el cual se creo webM, usando como codec de vídeo VP8. La idea fue muy buen recibida por parte de Opera y Mozilla, sobre todo este último por ser conocido como defensor a ultranza de una web libre… y sin licencias. En la otra cara de la moneda están Microsoft y Apple, ambos pertenecen al consorcio de la MPEG LA, con lo que no hace falta decir que para ellos h264 está fuera de discusión, y lo mismo para h265.

VP9 nace de la evolución de VP8, y realmente mejora bastante. Es cierto que H264 es ya también un codec viejo y que su sustituto, h265, ya está en la calle. Google compara en todo momento VP9 con H264, y realmente pare ser justos tendría que compararlo con h265. No obstante, es cierto que las diferencias entre VP8 con respecto h264 eran superiores a VP9 con respecto a h265, siendo este último aun superior.

Que la web adopte un estándar en cuanto a codec de compresión de audio y vídeo sería la mejor noticias de todas, ya que cualquier vídeo que se crease para la web podría verse perfectamente en cualquier dispositivo, sin tener que tener diferentes versiones para diferentes navegadores, lo que es una verdadera lacra. Internet Explorer soporta webM a través de una capa que crea Google para él, Opera, Mozilla y Chrome tienen soporte nativo, y es Apple el único que no da soporte de ningún tipo. Pero aun así, quien decidirá si webM (ya sea con VP8 o VP9) triunfará, será sin duda alguna los proveedores de contenidos, y aquí YouTube tiene mucho que decir.

A los distribuidores les compensa usar webM, no tienen que pagar royalties. Con h264 parecía claro porque cuando apareció no existía ninguna alternativa viable, pero h265 y VP9 aparecen en el mercado casi al mismo tiempo! Y con una calidad muy muy similar. Actualmente no hay hardware en el mercado para permitir la aceleración hardware ni de uno ni del otro (principal problema a la hora de reproducir vídeo en dispositivos pequeños como móviles y otros), lo cual significa que realmente VP9 puede ser una gran apuesta. Una de las llaves del cambio la tiene Google, ya que el poder de YouTube es indiscutible. Hasta el momento, Google codifica todos sus vídeos en VP8 y H264, pero parecería lógico pensar que no implementará h265, sino que comenzará a codificarlos en VP9.

Para Google o cualquier otro distribuidor de contenido, usar VP9 h264 implica reducir incluso al 50% el peso de los vídeos, y eso se traduce de nuevo en cientos o miles de millones de euros al año en concepto de ancho de banda o almacenamiento. Google es el primer interesado de empezar a usar un codec de vídeo más avanzado. Es evidente que Chrome, Opera y Firefox darán soporte completo a VP9 y OPUS (el codec de audio). Con esto Google tendría más o menos el 70% del mercado de los navegadores cubiertos, aun más si contamos el tráfico de los dispositivos móviles. Si Google abandona totalmente h265 y YouTube comienza a partir de ahora a codificar todo en VP9, para TODOS los fabricantes de móviles les interesará tener un decodificador hardware de  VP9, así como soporte en las gráficas actuales de equipos de sobremesa. El peso que posee YT es demasiado como para que la competencia en cuanto a gerra de codec se refiere (Apple  y Microsoft) puedan resistirse. La historia nos cuenta que Microsoft daría soporte para webM sin demasiados problemas, un poco a regañadientes, pero sin problemas. En cambio Apple posiblemente tardaría años en implementarlo, si miramos atrás, Apple sería capaz incluso de dejar a sus usuarios sin YouTube en sus dispositivos si hiciese falta.

En cualquier caso, VP9 sería capaz de reducir hasta en un 50% el tamaño de los archivos de vídeo manteniendo la misma calidad de este respecto a h264, y por otro lado como ya se ha dicho no hay que pagar absolutamente nada por usarlo del modo que se quiera, ya sea comercialmente como personalmente.

vp9

En el vídeo que mostraron, en algunos momentos se obtenía una reducción incluso del 63%, por supuesto manteniendo la misma calidad visual, basada probablemente en métricas como PSNR o SSIM. En esta ocasión no he podido realizar pruebas por mi mismo, no conozco ningún codificador VP9 en el mercado que sea decente, con lo que tendremos que fiarnos de lo que nos dice Google, al menos como vimos en el caso de WebP era cierto.

 

-HTML5

Para terminar de hablar sobre Chrome, dieron un rápido repaso a las nuevas características que han añadido, así como características que ya se disponían para poder comprobar el potencial que tienen.

Ese fue el caso del nuevo sistema de compresión de Chrome para dispositivos portátiles, que usa un proxy de Google para reprocesar las webs y hacer que disminuyan de tamaño, con la idea de que se carguen antes o disminuir el consumo de datos. En esta función soy algo crítico, ya que usar un proxy implicaría que TODO nuestro tráfico estaría pasando por su servidor, algo que a los que nos gusta la privacidad no es que sea muy halagüeño.

Por otro lado se aununció a medio plazo un toolkit para crear aplicaciones webs con la misma estética que estamos últimamente viendo en Google para con Android, aunque no se dijo demasiado de esto, y aun sin fecha de ningún tipo.

La presentación terminó demostrando la viabilidad y la evolución con tecnologías como WebRCT, WebSockets, WebAudio… Básicamente 5 individuos con diferentes dispositivos como un móvil, tablets de diferentes tamaños… todos juntos al mismo tiempo eran capaces no solo de jugar (cada cual desde su dispositivo), sino que además entre todos ellos (los dispositivos) conformaban el mismo circuito del juego. Es decir que no solo se sincronizaba en tiempo real las acciones de cada uno, sino que también lo hacían las pantallas. Eso da lugar por supuesto a aplicaciones en las que tener un dispositivo cualquiera nos sirve como segunda o tercera pantalla de la misma aplicación web, o incluso como un dispositivo de entrada.

 

 

Google+

Soy un firme defensor de Google+, y aunque aun muchos (sobre todo aquí en España) se resisten a usarlo, lo cierto es que es de esas cosas que cuanto más las usas más adictas a ellas te vuelves. Por increíble que me parezca, aun hay muchos que no saben siquiera que es! Muchos otros lo llaman simplemente el FaceBook de Google, pero creo que sería algo despectivo, Google+ es mucho más que pueda ser un FaceBook, y a los echos me remito. La mejor prueba de ello, es que hasta que Google+ no vio la luz, FaceBook no aplicaba ninguna sola mejora desde hacía mucho tiempo. En lo que lleva Google+ para el público, FaceBook se ha visto obligado a implementar video llamdas en el chat, revisar una y otra vez sus políticas de privacidad, tapar agujeros y problemas de todo tipo, añadir publicidad molesta en todos lados… incluso han cambiado en 3 veces la estética de FaceBook para hacerse más parecido curiosamente a Google+ o a usar hastags.

Google+ por su parte comenzó siendo una interfaz mucho más sencilla que FaceBook, controles y políticas de privacidad mucho mas consistentes, un nuevo modelo de interacción social más parecido a la vida real con los «Círculos», es decir, cuando añades a alguien no lo añades como amigo, lo añades dentro de un círculo de confianza, ya sean amigos, familias… algo así como «grupos», pero de una forma mucho más intuitiva y mucho mejor integrado. Google+ apareció con una de las características más sorprendentes que había (y hay), como pueda ser los HandGouts y la capacidad de poder realizar video llamadas de hasta 10 personas de forma simultánea, en las que todos los interlocutores pueden verse unos a otros, hablar, escuchar…

Bien, pues si hace unas semanas Google+ era como debía de ser una red social, Google desde el Google I/O prácticamente no ha dejado un solo lugar de Google+ sin tocar, introduciendo hasta 41 cambios, y por supuesto nos dejan un pequeño vídeo introductorio de todo ello: AQUI. Básicamente hay tres grandes bloques en los que reparten los cambios: Los Streams, Hangouts y Fotos.

Para empezar, lo más llamativo es la nueva interfaz, totalmente rediseñada. Cada entrada de otros usuarios, sugerencias o comunidades, tiene formato «tarjeta», los hastags son automaticamente detectados y ordenados en cada una de ellas en función de los que estén siendo más usados en ese momento, la interfaz es increíblemente fluída, dinámica y moderna. Se maximiza el espacio de trabajo, mostrando los post (los streams) en una, dos, tres columnas, dependiendo del tamaño y resolucón del monitor, y también se auto oculta la barra de navegación principal de las opciones.

googleplus(Con la barra lateral mostrada)

 

Respecto a HangOuts, Google por fin enseña lo que llamaban proyecto Babel, el primer paso para la integración completa de sus servicios de mensajería. Hasta hace muy poco disponíamos por un lado de Google Talk dentro de GMail o aplicación de sobremesa, Gtalk en los dispositivos portátiles, Messenger dentro de Google+ en los dispositivos portátiles, HangOuts dentro de Google+… no es que fuese confuso porque realmente todos podían «hablar» entre todos, pero un poco caótico si que resultaba. Google elimina así de un plumazo parte de toda la mensajería viaje que tenía y la unifica bajo «HangOuts». Tanto Google+ como Gmail ya no existe Google Talk (aunque en Gmail aun se puede volver a la versión antigua, GTalk). En Android o iOS aparece la aplicación HangOuts que sustituye (o actualiza) Google Talk, y la única que aun queda es el «Messenger» que instala Google+ en Android. En la última actualización de Google+ ya se avisa de su inminente desaparición, y se ha dicho que no se ha eliminado ya porque quieren pasar todas las conversaciones guardadas en él al historial único de Gmail, después de eso desaparecerá también.

Respecto a la integración por tanto, Google HangOuts comienza a unificar todos los servicios de mensajerías, y es de esperar que dentro de poco Google Voice sea integrado también dentro. Pero Google HangOuts no solo es una integración de sus servicios de mensajería, sino que hay más. Su interfaz cambia de forma notable para pasar a ser más atractivo, puede verse perfectamente la foto de perfil de Google+, se añaden infinidad de emoticonos, la posibilidad (por fin) de poder enviar imágenes, la posibilidad de verificar el número de teléfono para encontrar a tus contactos o tener una conversación con más de una persona a la vez (Google no lo llama grupos, sino conversaciones)

En estos días, en los que programas de mensajería como WhatsApp o Line, esto no es algo que sea muy novedoso realmente. No obstante, el nuevo HangOut posee ciertos beneficios que no posee ningún otro programa de mensajería, aunque aun deben de pulirlo algo más, es mejorable. Decía que aun así posee ciertas características que lo hacen destacable frente al resto. Es cierto que no pueden compartirse otras cosas como vídeos, contactos… o seguramente la principal carencia para muchos, el no poder cuando un contacto está o no conectado (cosa que no comprendo cuando en WhatsApps y otros no es algo que importe)

En primer lugar, HangOut es totalmente multiplataforma e integrado con todos los productos de Google. Eso quiere decir que podemos mandar un mensaje o hacer una videollamada o compartir una imagen a cualquier otro usuario de HangOut!! Es decir, dentro de unas semanas o meses que todos hayan terminado la transición a HangOut, cualquiera podrá enviar un mensaje a cualquier otro que tenga Android (por tener integrado Gtalk (ahora HangOut), pero también comunicarse con cualquiera que tenga el correo abierto (cosa muy habitual), o también si tiene abierto Google+ por supuesto. Por otro lado los usuarios de iOS pueden instalar igualmente la aplicación.

En segundo lugar la video conferencia sin duda alguna. De forma sencilla podemos cambiar rapidamente a video llamada al estilo hangout, es decir, incluso con un total de 10 participantes simultáneos, o si lo preferimos tan solo una llamada de voz por supuseto. Y de nuevo, eso podemos realizarlo con otros usuarios de Android, o llamadas de vídeo PC-PC, PC-Android… o cualquier combinación que se quiera.

En tercer lugar, la forma en la que las imágenes se comparten es bastante diferente a como se comparten con WhatsApp, Line o cualquier otra aplicación de mensajería. HangOut es infinitamente menos intrusivo y respetuoso con la seguridad del usuario, sobre todo de su privacidad. Con Google HangOut cuando se comparte una imagen con la persona X, al destinatario le llega inmediatamente en pantalla la imagen, pero lo que realmente se hace es que HangOut manda nuestra imagen a compartir a Google+ Photos (aka Picasa) y crea en él un album con el nombre de la persona en el que se almacenarán todas las imágenes que compartamos con él. Una vez la imagen se transfiere a nuestro Google+ Photos, HangOut manda un enlace a la otra persona. Google NO ALMACENA en ningún lugar extraño nuestras fotos como hace WhatsApp por ejemplo, el usuario puede ver en todo momento sus imágenes enviadas por HangOuts y eliminar la que quiera cuando quiera. En comparación, cuando compartes cualquier cosa por WhatsApp este contenido va a sus servidores donde NO PUEDES GESTIONAR NADA, y en él permanecen sabe dios cuanto tiempo, siendo además teóricamente hablando, acceder a las imágenes o el contenido de otros usuarios.

 Google quiere enfocarse en lo que debería de ser un sistema de mensajería más amigable y personal, en el que no hay grupos sino conversaciones, en las que en cualquier momento cambias de forma natural a una video llamada en la que puedes hablar y ver a cada uno de los contertulios, con los que puedes compartir instantáneas que hagas en ese mismo momento en el móvil, desde una webCam o compartir una imagen que ya tengas en cualquier lugar. Sea como sea, lo cierto es que la principal ventaja que tiene es su interoperatividad, escribes un mensaje a un contacto y simplemente sabes que le llegará. 

Igualmente posee un añadido interesante que tampoco cuentan el resto de sistemas de mensajería. Cualquier usuario de Gtalk sabe que por defecto su historial de mensajes es almacenado en Gmail, en la etiqueta Chats, de modo que escribas lo q escribas desde cualquier dispositivo, tu historial estará allí. Con la inclusión de HangOut se intentan unificar igualmente el sistema de almacenaje de dichos mensajes, en vez de estar desordenados como estaban ahora, ahora se organizarán por conversación (que no por individuo, ya que un hangout puede estar constituido por muchos). Este sistema nos garantiza que da igual que escribamos desde donde escribamos pq nuestro historial siempre estará actualizado. Y por supuesto en el momento que deseemos podemos eliminar de forma sencilla el historial con dicho contacto o simplemente archivarlo. En comparación WhatsApps por ejemplo, te permite como mucho crear una copia de seguridad en la partición /sdcard o enviarlo por correo, en el caso de iOS tan solo enviarlo por correo, con lo que poder guardar un historial estés donde estés, es interesante.

 hangout

 

La tercera característica reformada a conciencia fue Photos. Originalmente Google poseía hacía tiempo el portal Picasa, y con él Google entraba dentro de la edición fotográfica y software de gestión avanzado para ellas. Picasa te permitía crear albums con tus fotos, ordenarlas, compartirlas de forma sencilla con otras personas… y por supuesto el software de escritorio para ello, con la posibilidad de subir a Picasa las fotografías. Esto ha evolucionado con el tiempo, y bastante. Para empezar, Picasa empezó a ser mucho más inteligente, compartir imágenes era más sencillo y el software de gestión permitía etiquetar fotos, comentarlas, ver la geolocalización de donde se tomaron, edición básica de las fotos e incluso actualmente Picasa es capaz de identificar de forma automática las personas que aparecen en las fotografías… y lo hace francamente bien. Con el nacimiento de Google+, Google poco a poco pasó a integrar Picasa en él, hasta tal punto que a día de hoy Picasa como gestor online de fotografías casi no existe, y ha sido sustituido casi por completo por Google+ Photos. En realidad aun es posible acceder a la interfaz antigua, pero supongo que terminará por desaparecer.

Google+ Photos es más que un album web para organizar fotos, desde él podemos administrar los permisos o los accesos a nuestras fotos, pero también manipularlas o editarlas. Hace ya algún tiempo, Google permitía cierta edición a las fotos que teníamos, como pro ejemplo añadir algunos efectos. Lo que ahora se ha hecho es extender y en mucho estas herramientas, con la inclusión de un nuevo abanico de ellas. Es evidente que no no es un editor de fotos como pueda serlo GIMP o Photoshop, pero desde luego sí lo suficientemente potente y versátil como para «arreglar», embellecer y mejorar considerablemente las fotos que tengamos allí.

Para empezar, incluye lo que han llamado «highlights», que no es sino un modo de mostrarnos a nosotros mismos nuestras mismas fotografías, basado no en un orden aleatorio de estas o basadas en un orden cronológico, sino en un conjunto de factores. Por ejemplo, highlights descartará por defecto imágenes duplicadas o que sean muy borrosas o estén mal expuestas, primará antes fotografías en las que estemos con seres familiares/queridos que aquellas en las que estemos solos o sean de paisajes, ponderará positivamente aquellas fotos que sean similares pero en las que estemos sonriendo. Recordar que con Google Instant todos los usuarios de Android si activamos dicha función, TODAS las fotos que hagamos serán subidas automáticamente a nuestro espacio en Google+ (por supuesto por defecto no compartidas). Gracias a la tecnología Zero-Shutter-Lag es más frecuente realizar varios disparos cuando queremos tomar una foto de amigos, momentos… no porque una pueda salir borrosa, sino porque a lo mejor en una de ellas sale alguien con mala cara, un destello, un… y al final terminamos a lo mejor con 5 fotos similares en las que las variaciones son leves. Highlights se encarga de desechar aquellas que considera «fracasos». Aun así, highlights no elimina nada, tan solo es un modo de mostrarlas, en cualquier momento podemos decirle a Google que queremos verlas de la forma tradicional.

Añade también lo que han llamado «Enhance», que sería lo más similar a la edición directa, la aplicación de filtros. Así por ejemplo se puede realizar un ajuste automático, mejorar la distribución tonal, la suavidad de la piel, reducción de ruído, le balance de blancos… sin contar que en todo momento podemos alternar entre la versión editada a la versión original.

Por último incorporan lo que a mi parecer es lo más interesante «Awesome». Awesome no es una herramienta que pueda activarse de forma manual siempre que deseemos, sino que podremos activarla solo cuando el sistema reconozca cierto patrón en una serie de fotografías tomadas. Así por ejemplo, si nuestro album contiene una sucesión de imágenes variadas nos dará la opción de crear un collage con ellas, o si detecta que hay fotos iguales pero con diferentes exposiciones nos ofrecerá la opción de fundirlas en una imagen HDR, o crear una imagen panorámica en caso de que tengamos diferentes imágenes tomadas a lo largo de un paisaje. Otra de las opciones de Awesome, será crear un «vídeo» con diferentes imágenes tomadas en un corto período temporal. Dependiendo siempre de las fotos que tengamos en nuestros álbumes, Awesome nos ofrecerá una u otras opciones, de nuevo siempre dependiendo del tipo de contenido de las imágenes, del número de ellas, de…  En realidad es una gran idea, el sistema detecta de forma automática que es lo que podrías hacer con esas imágenes, o suponer que es lo que te gustaría hacer con ellas por como son o como se tomaron.

Al margen de todos los añadidos nuevos, recordemos que Google+ Photos nos permite subir imágenes Photosfericas o incluirlas donde queramos.

photos

Como coletazo final a Google+, y no solo relativo a Google+ Photos, Google anunció como había hecho días antes, que comenzará la unificación del espacio en nube que disponen TODOS los usuarios. Hasta la fecha de hoy, cada usuario tenía una bandeja de entrada en Gmail de 10GB, y 5GB adicionales para Drive e imágenes. El cambio está en que con la unificación (que está en curso), no dispondremos de dos espacios diferentes, sino un único espacio de 15GB compartido para el Correo, Drive e imágenes. De este modo un usuario no se tendría que constringir a los 5GB para Drive mientras mantiene su correo electrónico casi vacío, y al revés, para aquellos que usen intensivamente el correo podrán hacer uso de ese espacio extra que antes había en Drive para sus correos. No nos amplian el espacio gratuito, pero nos dejan usarlo como deseemos. Para los usuarios que tienen contratado espacio extra, funcionará exactamente igual, el espacio comprado extra será igualmente compartido para todos sus productos, con lo que lo gestionará como desee.

 

Google Maps

La última actualización de la que vamos a hablar es Google Maps, el cual también ha recibido una fuerte actualización, aunque esta en contrapartida aun no está disponible al público, por ahora tan solo es accesible por invitación, cualquiera puede solicitar una y esperar a que Google vaya ampliando la muestra de personas: SOLICITAR INVITACION. 

Al igual que con Google+, Maps cambia radicalmente, y eso que siendo un sistema de mapas fundamentalmente, no cabría esperar demasiadas modificaciones

Para empezar, de nuevo lo más llamativo es la nueva interfaz, se ha limpiado entera. Se acabó una barra lateral izquierda para las búsquedas o para señalar las ubicaciones buscadas. Ahora dispondremos de un solo cuadro de texto superpuesto encima del mapa donde realizar las búsquedas, en el que también se nos mostrarán diferentes «tarjetas», referentes a nuestras búsquedas o a lugares ya buscados anteriormente. Todo lo demás en la pantalla es mapa. A la vez que vamos escribiendo, el cuadro de texto se va actualizando al momento y sugiriendo diferentes ubicaciones, y una vez disparada la búsqueda, los resultados son mostrados directamente sobre el mapa. Siempre se nos dará la opción no obstante de acceder a otra página para ver listados uno tras otros las diferentes ubicaciones posibles. De este modo Google parece dar mucha mayor importancia al mapa en sí mismo.

maps

La idea es clara, de primero interaccionar con el mapa, y de segundo interaccionar con el mapa. Actualmente, la nueva interfaz tan solo tiene dos modos de visionado, satélite (llamado Earth) y mapa de carreteras (llamado Map). En principio faltan algunas opciones que tenía el Maps viejo como pueda ser las imágenes en 45º, el visionado del tiempo, mapa de elevación o la selección a voluntad de que elementos queremos que el mapa muestre o no (al menos ninguna de dichas opciones la he podido encontrar). Pero no olvidemos que el nuevo Maps está en versión de pruebas y por ello no está habilitados para todos, y sabemos que no lo estará al menos hasta verano. Esto quiere decir que si ya pueden cambiar lo que quieran cuando está en producción, cuando está en fase de pruebas más aun, de ahí el dar invitaciones para usarlo por supuesto, para que se puedan enviar reportes, sugerencias, fallos…

El modo de mapa tradicional, como el mostrado arriba, es sumamente rápido, tanto al cargarlo como al desplazarnos por él. Cuando se busca cualquier cosa en él los puntos de interés se muestran directamente en el mapa, y es al presionar cualquiera de ellos cuando debajo de la barra de búsqueda se nos muestra que es, si queremos obtener las direcciones para llegar hasta ese punto, información de ese lugar, si ese lugar ha sido recomendado por alguien de nuestros círculos, si queremos escribir alguna reseña, o incluso acceder a imágenes internas del lugar. Por otro lado, al igual que en Maps para Android, si acercamos el mapa a un nivel más bajo, veremos «crecer» los edificios 3d sin texturizar, aunque en este modo no podremos girar el mapa. Por otro lado si desplegamos la barra inferior, se nos mostrarán imágenes de interés cercano. También podremos ver en tiempo real el tráfico de la zona, accidentes que acaben de ocurrir…

Las direcciones se han modificado también, ahora no solo es mucho más sencillo hacer un como llegar a… sino que se nos brindan muchas más opciones. En el momento que queremos ver la dirección de un lugar y el como ir, podremos elegir entre ir en coche, transporte público, bicicleta, avión… y por supuesto andando. Es evidente que dependiendo del País así como la ubicación de origen/destino podrás solicitar dicha información o no. Podrás escoger también en cada uno de los modos diferentes opciones, así por ejemplo si seleccionas en coche si quieres evitar o no autopistas de peajes, o si prefieres el camino largo al rápido. Si es en transporte público si quieres restringirlo a autobuses, o solo a trenes, o aquella combinación que sea más rápida… etc etc. Presupongo que la fiabilidad de estos datos dependerán siempre en última instancia de cada País. Aquí en España por ejemplo, en las pruebas que he hecho, Maps no tiene problema de devolverme resultados en los que combina perfectamente autobuses, trenes e ir andando, especificando perfectamente la hora de salida de cada uno de ellos, el tiempo estimado que tardan en llegar…

Por otro lado la edición de rutas es igualmente sencilla, si deseamos cambiar el origen o destino que están en el mapa, tan solo tenemos que mover el «pin» del mapa, arrastrarlo hasta otra posición y automáticamente se actualiza. Podremos ver los pasos a pasos a seguir dentro del mismo mapa debajo de la casilla de búsqueda, o más cómodamente en una pantalla dedicada a ello.

Otra novedad, es que Maps nos mostrará y señalará aquellos lugares no solo que tengamos añadidos a «nuestros lugares», sino que también podremos ver aquellos lugares que nos sugieran nuestros círculos. Básicamente, cuanto más vayamos usando Maps y nuestros contactos, este será más social y más cómodo a la hora de encontrar cualquier lugar, o por supuesto el ir a alguno.

El acceso a StreetView es inmediato, basta con hacer clic en cualquier lugar del mundo para que debajo de la barra de búsqueda nos aparezca el lugar, la dirección y el darle a StreetView, no hará falta el arrastrar el muñequito. Si la ubicación escogida no dispone de StreetView, este nos llevará a la ubicación más cercana a pie de calle. En cualquier caso, de nuevo si la barra de exploración inferior está desplegada nos mostrará  fotos y/o lugares cercanos y útiles, así como otras imágenes de StreetView. En la parte inferior izquierda podremos ver en todo momento también un pequeño mapa que muestra donde nos encontramos.

maps2

 

¿Que pasa si alternamos al modo satélite? Las imágenes 45º por ahora han desaparecido (no sabemos si las pondrán o no), y tampoco hay un modo 3D que podamos seleccionar, ya que este se disparará automáticamente. El modo satélite funciona exactamente igual al modo mapa en cuanto a búsqueda o direcciones, pero tiene otras características. Para empezar, podremos ahora sí girar el mapa como queramos, y no solo acercarnos o alejarnos de él, sino que también podremos escoger entre 3 diferentes modos de inclinación de cámara diferentes! necesario por supuesto para el modo 3D si queremos ver la profundidad como es debido. El modo satélite funciona igualmente bien, pero como era de esperar no es tan rápido y fluido como es el modo terreno, además en mi caso concreto hizo que el navegador fallase un par de veces. Por otro lado necesitaremos de un navegador con WebGL y un equipo relativamente capaz si vamos a una ciudad que esté mapeada íntegramente en 3D, como pueda ser New York. Algunos han dicho que al igual que le pasó a Apple, Google tiene problemas en dicho mapeado y hay errores gráficos. Bien, lo que sí puedo decir es que esos errores se producen ciertamente en el caso de Maps cuando el mapa no está cargado del todo, si se espera un poco vemos como edificios, terreno y otros se van renderizando y perfeccionando, hasta que la zona está totalmente cargada. Hay que tener en cuenta que no solo es un gran trabajo para el PC, sino que descargar los datos 3D en el PC requiere su tiempo.

Para terminar, el modo 3D permite alejarnos del suelo más allá de la proyección plana del mapa del mundo, y podremos salir incluso al espacio al puro estilo Google Earth (aunque con limitaciones por supuesto), hasta el punto de poder ver en tiempo real la atmósfera o la posición del sol respecto a la tierra.

 

Google Maps para Android/iOS también tendrán sufrirán una importante actualización, se integrará mapas con el navegador paso a paso en muchas ocasiones, lo que resultará muy cómodo a la hora de conmutar entre una dirección y el querer llegar hasta ella,  y muchas de las funciones de Maps (de PC) serán integradas igualmente en el Maps de dispositivos portátiles. La interfaz ha cambiado igualmente y la versión para tablets aprovechará mejor la pantalla y la interfaz se adaptará mejor a ellos, pero por desgracia en este caso Google no ha liberado ninguna versión de pruebas, así que habrá que esperar a Junio/Julio a que la liberen. En realidad no se sabe el mes, solo que será en verano. Era de todos modos normal que Google no lanzase para nadie la versión de Maps, ya que a los minutos estaría diseminada por doquier, y tendrían que haber implementado sistema de control por cuentas habilitadas para tal efecto… lo cual sería más trabajo para ellos.

 newyork

 

Google Play for Educations

Para terminar, y brevemente, Google anunció que igual que posee un programa especial para universidades y colegios de sus Google Apps, un Google Play para universidades, colegios y otros. La idea es sencilla, dar acceso personalizado a Google Play, con categorías específicas para la enseñanza, pero más importante, un sistema de licencias masivas para las aplicaciones que distribuya dicha universidad o colegio inscrito. Es decir, dicho de otro modo que pueda entenderse mejor, si una universidad tiene en su cuenta 500 licencias para todas las aplicaciones categorizadas para enseñanza, dichas aplicaciones la podrán instalar hasta 500 alumnos del centro de forma totalmente gratuita.

Google Apps ha sido un éxito a nivel mundial, cada día que pasa más centros de enseñanzas (y empresas por supuesto) se adhieren a él, lo que permite a miles y cientos de miles de alumnos a beneficiarse de los servicios de Google de forma totalmente gratuita. Google Play para la enseñanza viene a ser un poco lo que es DreamSpark de Microsoft para ellos, una plataforma con la que acercar software (aplicaciones en este caso) a los alumnos, sin que estos tengan que sufragar ningún gasto. Además es un movimiento inteligente, acercar la tecnología y Android a más personas es siempre bueno para Google.

Sea como sea, aunque por supuesto sea bueno para Google, será igualmente bueno para cientos de miles de alumnos, con lo que bienvenido sea.

Google I/O 2013: Resumen del Keynote, Parte 1

Sin duda alguna las 3 horas y media que duró el Keynote, y que estoy seguro que muchos seguimos con bastante atención, nos dejaron un buen chorreón de novedades. Este año, Google decidió enfocar el Google I/O para los desarrolladores en vez de enfocarse tanto en el usuario final, lo cual es un giro respecto a los últimos años. No quiere decir que se olvidasen del usuario, pero sin duda alguna se hizo un gran énfasis en los programadores alrededor de todo el mundo.

Novedades fueron muchas, algunos cambios radicales en sus productos, otras de gran calado y otras más sutiles pero sin duda bien recibidas. Los grandes ausentes en el Keynote fueron sin duda alguna Android 4.3 o Android 5.0 y al propio Sergey Brin (Cofundador de Google junto con Larry Page), aunque por suerte pudimos ver al final del Keynote a un Larry Page ausente en el Goolge I/O 2012, aun sin recuperarse del todo de su parálisis de cuerdas vocales.

Aun que no se anunciase en ningún momento una nueva versión de Android, no por ello no dejó de ser un gran foco en todo el Keynote, y así quedó demostrado cuando poco después de comenzar se anunciaba que Android no solo era desde hacía mucho tiempo el sistema operativo de dispositivos móviles más usado, sino que si el año pasado se contaron las activaciones en 400 Millones, ahora mismo en 2013 son 900 Millones! Más del doble con respecto al año pasado, lo cual es algo impresionante. De cara a los desarrolladores, el llamamiento fue bastante claro, en este último año los beneficios de estos se han disparado igualmente. Hagamos una recapitulación un tanto rápida de las novedades que nos dejó, y que seguro que más de uno ya está aprovechando.

En cuanto a aplicaciones instaladas, Apple anunciaba hace unos minutos que acababa de sobrepasar la friolera de 50.000 Millones de aplicaciones descargadas, mientras que ayer en el KeyNote se hablaba de a ver superado los 48.000 Millones, con más de 2.500 Millones este último mes. Teniendo en cuenta estas cifras, eso significaría que en una semana o dos, Android sobrepasaría también a Apple en aplicaciones instaladas/descargadas por el usuario. Esto implica sin duda alguna otro handicap de cara a los desarrolladores adicional, ya que Android no solo es la plataforma más usada, sino que además también lo es en cuanto a aplicaciones instaladas, y como ya hemos dicho los propios beneficios para los programadores también se han disparado este último año.

 

 

Google Play Services

Hace ya tiempo, Google empezó a servir de forma totalmente automática y sin preguntar al usuario, una «aplicación» en sus dispositivos Android llamada Google Play Services. Por entonces se dieron muy pocas pistas de que papel iba a desempeñar, parecía una aplicación de sistema que de un día a otro empezó a aparecer en los dispositivos. Con el tiempo, se comenzó a saber que Google Play Services era una capa intermedia en el framework de Google para poder proveer sin ningún tipo de problema de actualizaciones de sus servicios a TODOS los dispositivos Android sin importar la versión del OS de estos. Ayer se lanzó una actualización bastante profunda de este, posiblemente hoy disponga de ella el 90% de todos los dispositivos de Android y aun no se han dado cuenta, puesto que como he dicho Google Play Services no aparece como actualización en Play Store, se actualiza de forma automática y transparente al usuario. La pregunta es: ¿Y que nos puede traer esto? Muchas novedades. De este modo Google cada vez más independiza la versión que se tenga de Android, puesto que aunque no haya anunciado ninguna versión nueva de este, practicamente todos los usuarios de Android disfrutarán de los siguientes añadidos. No olvidaros por supuesto de echarle un ojo a la aplicación que gestiona estos servvicios y que muchos aun creen que era para unificar las configuraciones: «Google Settings»

services

 

-Google Maps API v2: Ya estaba incluido

-API de localización:

Se ha introducido una API nueva en Google Play Services de localización, que permitirá a las aplicaciones aprovecharse de esta nueva tecnología de Google. Por supuesto los desarrolladores tendrán que actualizar sus aplicaciones o crearlas con esta API en mente, pero el usuario final podrá beneficiarse como es natural de estas mejoras. La nueva API de localización nace con 3 capacidades fundamentales

La primera, llamada Fused Location, une de forma sencilla los tres sistemas de localización disponibles (torres GSM, WIFI y GPS), proveyendo a las aplicaciones de forma sencilla de un nuevo sistema unificado de geolocalización, que se ha asegurado ser mucho más rápido, preciso y con un sustancial consumo menor de batería, se hablaba de un 1% de batería por hora… lo cual de ser cierto es sorprendente.

La segunda se ha llamado GeoFencing, y permitirá a las aplicaciones crear (un máximo de 100 por aplicación) zonas geográficas virtuales, en las que la aplicación será informada en cualquier momento que el usuario sale o entra en cualquiera de estas zonas. De nuevo hay que pensar desde el punto de vista del desarrollador, y el usuario final el que se beneficia de las nuevas aplicaciones. Esto permitirá la creación de nuevas aplicaciones e ideas bastante novedosas. Pensemos en aplicaciones como Ingress que dependen totalmente de la ubicación geográfica y de quienes se encuentran en zonas específicas… las aplicaciones de esto son muchas, y estoy seguro lo veremos en las próximas semanas y meses.

Por último, la tercera, Activity Recognition, permitirá a las aplicaciones conocer a través de los sensores del dispositivo (sin necesidad de tener el GPS activado) si el usuario se encuentra montado en un coche, si se encuentra caminando o si se encuentra en bicicleta. Automáticamente pensamos en aplicaciones tipo «trackers» que graban las rutas de los deportistas, o queremos guardar las del coche, o un sistema integral de rutas que vaya alternando según vayamos andando en bici o en coche… y por supuesto estoy seguro que los primeros que usarán este tipo de novedades son sin duda los chicos de Google, no podemos olvidar el propio Google Navigator.

 

-Google+ Sign-In

Google+ Sign-In ya fue lanzado hace unas semanas o meses, un sistema que rivalizaría con el inicio de sesión de Facebook, que permite a páginas webs acceder a sus servicios simplemente a través de nuestra cuenta de Facebook. Google llevó Sign-in a otro nivel, en el que no solo permite a las páginas webs el acceso a sus servicios a través del inicio de sesión unificado de Google+, sino que además Google+ permite el acceso (siempre que los desarrolladores usen Google+ Sign-In) a aplicaciones, servicios, una mayor visibilidad en el motor de búsqueda de Google, posibilidad de realizar funciones automáticas como la instalación de aplicaciones en nuestros dispositivos Android…

La principal novedad añadida, es que el proceso es ahora totalmente multiplataforma. Es decir, imaginemos que accedemos a los servicios X de la web Y a través de Google+ Sign-In a través del PC de casa. Al acceder la web nos pregunta que si deseamos instalar la aplicación de ellos (si aceptamos sin hacer mas nada la aplicación se manda a nuestro dispositivo Android). Luego, cuando dejamos el PC, si accedemos de nuevo a la web a través de nuestro dispositivo Android, dado que nuestra cuenta está añadida en nuestros dispositivos accederemos automáticamente a los servicios de dicha web, sin importar que lo hiciésemos desde el PC.

Son muchísimas personas las que usan estos sistemas de acceso en las webs para evitar tener que estar creando cuentas en ellas, pudiendo usar su cuenta de siempre. Es cierto que ahora mismo Google+ Sign-In no está tan expandido como Facebook Sign-In, pero conociendo como funcionan los chicos de Google, estoy seguro que cada día que pase empezaremos a ver los iconos de inicio de sesión de Google+ Sign-in por doquier.

No olvidemos tampoco el uso de Google+ Sign-In en las aplicaciones Android, puesto como veremos luego las aplicaciones de Android empezarán a implementar de forma masiva este inicio de sesión.

 

-Google Cloud Messaging

GCM es un servicio de Google que permite a las aplicaciones enviar mensajes Push a nuestros dispositivos. Ahora lo han integrado también en Google Play Services. Como se dijo, más dele 60% de las aplicaciones Android hacen uso de este servicio, con lo que cualquier mejora en este servicio será un éxito. Se han incluído 3 mejoras fundamentales, la mayoría posiblemente para el usuario final no entenderán su calado, pero puedo asegurar que para aquellos que hacen esas miles y millones de aplicaciones, implica poder optar por mejores aplicaciones, más ideas, mas versatilidad… y eso al final quien lo agradece como es evidente, es el usuario final

Por un lado se ha implementado conexiones persistentes con el servidor, con lo que ya no solo se trata de recibir una notificación Push y listo, sino que se puede mantener un canal de comunicación constante. En segundo lugar, y quizás más importante, la comunicación podrá ser bilateral (Upstream messaging), eso significa que no solo las aplicaciones podrán recibir mensajes desde los servidores, sino que podrán enviarlos. Esto unido a las conexiones persistentes, hace en toda regla un sistema de comunicación persistente y de ida y vuelta. Y como tercera característica, y posiblemente bien recibida para el usuario final, es la sincronización de notificaciones, pensar en cualquiera que tenga dos dispositivos Android con su misma cuenta de Google o con algunos servicios que usa tanto en un dispositivo como el otro, y recibe un mensaje o notificación en uno de esos servicios… ahora podrán recibir de forma simultanea la notificación en ambos.

 

-Google Play Game Services

Aunque las características ya explicadas son realmente interesantes, quizás de todas ellas la que pueda ser más sonada sea esta última. Google ha creado/incluido una plataforma integral para los juegos. De forma realmente sencilla, a través de un simple inicio de sesión por parte de Google+ Sign-In en las aplicaciones que sean compatibles, podrán acceder a este servicio de Google, el cual como puede imaginar la mayoría posee las características típicas de este tipo de plataformas. Pero además de todo ello, sin olvidar también que el sistema es independiente del dispositivo usado, dará igual que se acceda por el navegador, un tablet Android, un móvil…

En primer lugar lo que Google llama Cloud Save, es decir que nuestros progresos en cualquier aplicación podrán ser guardados en el servicio de Google, con lo que si accedemos incluso a otro dispositivo e iniciamos sesión en la aplicación podremos seguir por donde estábamos, o por supuesto si desinstalamos la aplicación y la volvemos a instalar.

En segundo lugar, los consabidos y siempre graciosos Logros, los cuales quedarán almacenados en el mismo sitio y podremos ver los de nuestros amigos de Google+, así como actualizaciones al estilo Facebook en nuestro perfil de Google+ con los diferentes logros o actividad en la aplicación.

Después de los logro tendríamos como es natural los tablones de puntuaciones, en los que la rivalidad es parte siempre del juego, sobre todo cuando se trata de luchar contra los puntos de tus amigos.

En último lugar y más importante aun, Google ha implementado igualmente en su servicio de juegos un sistema de multijugador, de este modo cualquier aplicación que quiera hacer uso de este servicio podrá convertirse fácilmente en aplicaicones multijugador en tiempo real!!. En el momento

 

En el momento de estar escribiendo estas letras, recordemos que Google Play Services ya se encuentra instalado en la mayoría de dispositivos Android, y eso significa que están preparados para estas novedades. Pero más aun, en estos momentos son muchas muchas aplicaciones en Play Store que ya están haciendo uso de estas características, que se han ido actualizando a lo largo del día de ayer y hoy… y mcuhas otras irán detrás. Por citar algunas que sé feacientemente, tenemos el gran juego Plague Inc (lo recomiendo realmente), gratuito y que ya hace uso del sistema de logros y otros. También tenemos Osmos HD que ya funciona en modo multijuador, o el gran World of Goo.

playgame

(Posiblemente en otro artículo me toque dar un tirón de oreja a la mayoría de los programadores, sobre todo esos usen sistemas de protección para puntos y otros tan simples, tardé 2 minutos en colocarme el primero en Plague Inc. y por lo que veo no fui el único que supo como hacerlo… aunque por los puntos del resto de los compañeros creo que los lograron a ojo, ya que el sistema los limitaría a (2^32/2)-1 y los puntos que lograron fueron los más cercanos a ese número. Pero como digo, eso otro día.)

 

Android Studio

A día de hoy el IDE usado y recomendado por Google para la creación de aplicaciones era Eclipse. Eran muchos los que preferían Intellij IDEA y parecía un grito a Google por parte de los desarrolladores. Google ha ido un poquito más lejos, y no solo se ha pasado al IDE basado prácticamente en Intellij IDEA, sino que lo ha dotado y perfeccionado para la creación de aplicaciones Android, empaquetando todo ello en un simple instalador.

El nuevo Android Studio se perfila pues como una herramienta mucho más sencilla de usar que ahorrarán literalmente horas y horas a cualquier desarrollador de aplicaciones, una integración mucho mejor, y herramientas realmente útiles. Lo cierto es que la presentación de Android Studio duró poco, y aunque YA ESTÁ disponible AQUI se ha advertido que aun está en desarrollo y que seguirán implementando mejoras, mejor integración… y nuevas funcionalidades. Como ejemplo, se mostró el sistema de visionado de los layouts de forma inmediata y de forma dinámica, de modo que el programador puede ver al mismo tiempo que escribe el código como va quedando las diferentes ventanas de su aplicación, e incluso multivisas para ver como quedaría en diferentes tamaños de pantalla o dispositivos.

Incorporará también visionado sencillo de la aplicación en los diferentes idiomas para una rápida corrección de estos, así como visionado inmediato de imágenes, iconos cargados, colores usados… dentro del mismo IDE. Al usuario es evidente que al final lo que le importa es tener aplicaciones de calidad, pero al programador que las hace darle herramientas que le van a ahorrar horas de trabajo… eso no tiene precio para ellos, sin contar que les permite crear aplicaciones de mayor calidad.

 

 

 

Google Play Developer Console

De nuevo,y pensando en los desarrolladores, Google mejora de forma considerable la consola de desarrollador, digamos que es el panel de control de los desarrolladores que usan para publicar y controlar sus aplicaciones en Play Store. Desde aquí se actualizan, se eliminan, se modifican, se les pone el precio… todo se gestiona desde él. En el afán de Google de maximizar la visibilidad y la calidad de las aplicaciones (y por tanto más beneficios para los dueños), implementa 5 funciones nuevas en el panel de control.

-Consejos para Optimizaciones: Mostrarán consejos útiles cuando una aplicación puede mejorarse en algún aspecto concreto, como traducirla a otros idiomas, compatible con diferentes resoluciones o tamaños de pantalla…

-Sistema de traducción de Aplicaciones: De forma realmente sencilla, pondrá al desarrollador un servicio (de pago evidentemente) para traducir sus aplicaciones a los idiomas que quiera. De este modo el programador se ahorrará en tener que buscar a traductores en diferentes idiomas, Google de forma sencilla lo hará por tí a golpe de ratón.

-Métrica de uso y rastreo de referencia: Herramientas de análisis que le dirán al desarrollador cuantas veces se buscó su aplicación, cuantas veces se visitaron, cuantas veces se instalaron, cuantas veces se desinstalaron.. todo elo de forma gráfica y sencilla. Esto de nuevo es realmente útil para mejorar la visibilidad de estas

-Gráficos de Beneficios: Google tiene una gran ventaja frente a cualquier otra plataforma que pueda exsitir, ya sea Windows Phone, iOS o BlackBerry. Google posee una serie de servicios que son bien conocidos para cualquier desarrollador no ya de aplicaciones móviles, sino de cualquier cosa. Google Posee el mejor motor de búsqueda que existe en el mundo, pero entre otras muchas cosas, también posee el mejor servicio (y de nuevo gratuito) para estadísticas webs con Google Analytics. Con lo que su integración dentro del panel de control, era de esperar, y no por ello menos útil

 -Beta Testing y publicación por etapas: Desde mi punto de vista la mejor adición de todas. Ahora será posible tener 3 canales diferentes para las aplicaciones, aplicaciones en fase alfa, en fase beta y en fase de producción, cada una de ellas pudiendo acceder a ellas el público si así lo desea el programador, así como pasar las aplicaciones de un canal de distribución a otro en cualquier momento. Y para mejorar esto, ahora puede enviar actualizaciones en pequeñas tandas para controlar mejor aun su distribución, sobre todo en aquellas aplicaciones que no están del todo probadas, esto es realmente útil en la fase beta, en la que el programador podría lanzar la beta a lo mejor tan solo a un 5% de sus usuarios, o a un 50%, o a un80%! y todo eso de forma automática, tan solo seleccionando dos opciones sencillas en el panel de control. Algo realmente útil.

developer

 

Google Play Store

Google Play Store es el alma mater ahora mismo de Android, o al menos una de ellas. Era comprensible que alguna mejora llegase en este aspecto. Tampoco se ha realizado un cambio radical ni nada por el estilo, pero si algunas mejoras. Para empezar, se ha includo en el Play Store para dispositivo una sección específica para tablets, o mejor dicho, un apartado para recomendaciones específicas para tablets. Recordemos que hace muy poco salió la versión 4.0 del Play Store, con lo que se ha terminado de pulir pequeños defectos de interfaz, para que todo esté mejor integrado y con un diseño más común a todos los productos de Google.

Se mostró evidentemente también la remodelación del Play Store vía Web, que aunque aun no se ha realizado el cambio, ahora mismo si se accede a «My Books» podemos ver un poco como será el nuevo diseño, con una barra lateral más cómoda y visible, una navegación más sencilla quizás. En el KeyNote se pudo ver como sería perfectamente, y es de esperar que llegue a todos los usuarios en las próximas semanas.

play

 

Google Play Music All Access

Otra de las grandes novedades y lanzamientos de Google ha sido lo que se ha llamado Google Play Music: All Access. Básicamente se ha ampliado el servicio de Google Play Music que ya se tenía, y se ha creado All Access, un servicio de suscripción mensual para acceder a TODO el catálogo de Google Play Music. Dicho de otro modo, el Spotify de Google.

El servicio estará en principio tan solo disponible en Estados Unidos, aunque es de esperar que en breve se unan muchos otros países (afortunadamente en España es de esperar que no tarde demasiado). Tendrá un precio final de 9.99$ mensual, lo que sería al cambio unos 8€ aproximadamente, y se podrá disfrutar de 30 días totalmente gratuito. Se pondrá en marcha en Junio.

A priori podría verse como un sistema igual a Spotify, pero posee grandes ventajas frente a este. En primer lugar, estará disponible TODO el repertorio de Google Play Music (Muy superior a Spotify), en segundo lugar recordemos que nuestros dispositivos disponen de una integración excepcional de todos los productos de Google, con lo que podríamos escuchar en la radio cualquier canción, activar por ejemplo Google Search o Google Search Music para identificar la canción, y una vez identificada nos llevaría directamente a Play Music para escucharla, descargarla, comprarla… por supuesto si tenemos All Access, podríamos añadirla de inmediato a nuestra biblioteca.

Pensar también en el caso de escuchar cualquier artista, o usar Google Search Voice para buscar los álbumes de un artista. Desde ahí a Play Music, desde ahí nos podrá decir perfectamente que más discos tiene dicho artista e incluirlos a nuestra biblioteca, o a nuestra lista de reproduccion! La cual podemos modificar, a voluntad con un simple gesto para eliminar las canciones o añadir otras nuevas.

Por otro lado, de nuevo es totalmente multiplataforma, es decir que una vez tengamos All Access podremos usarlo como usamos ya Google Play Music, desde cualquier navegador Web, desde el móvil… da igual que estemos en el PC, en nuestra casa o en cualquier lugar del mundo, una simple conexión a internet es suficiente.

Como era de esperar, la aplicación Google Play Music para Android se ha actualizado, tanto para adaptarse a All Access como para realizarle un buen lavado de cara, de nuevo para que sea mucho más consistente con el nuevo diseño que está optando Google en todos sus productos. ¿Me pregunto cuando le tocará a Gmail?. Los apartados de música reciente se ha modificado por «Listen Now» que de forma inteligente sugerirá que deseas escuchar, en función de lo más escuchado, lo recientemente, los géneros… y también se ha facilitado el acceso a comprar la música que se desee o ver artiscas/canciones relacionados.

 music

 

Google Search/Google Now

search

Posiblemente pocas tecnologías más interesantes y útiles hay ahora mismo en el mercado. Desde que Google añadiese el pasado año Knowledge Graph, hemos visto como prácticamente Google nos responde a cualquier pregunta que hagamos, desde simples operaciones aritméticas, información concreta de un artista, autor, pintor… pero no me refiero a resultados de búsqueda, sino información inmediata en pantalla. Cuando se hace uso de Google Search Voice el resultado es cuanto menos increíble, nos basta apretar un botón para hacer una pregunta cualquiera, y os aseguro que con una alta probabilidad Google nos muestra la respuesta en el móvil.

Una persona no es capaz de entender esto hasta que quizás un día se decide a probarlo no para intentar impresionar al que tiene al lado, sino para su propio uso. Entonces es cuando no vuelve a olvidar que tiene dicha función. El otro día sin ir mas lejos, era muy tarde o quizás era muy temprano, y se me ocurrió ir a ver salir el sol. No tenía un PC a mano y aunque lo hubiese tenido me habría costado bastante encontrar en algún sitio a que hora exactamente salía el Sol en el lugar que estaba. En cambio me pregunté que no pasaba nada por intentarlo: «A que hora amanece hoy?» Y la respuesta fue bien sencilla: «A las 7.25 am en XXX», siendo XXX donde me encontraba por supuesto.

Desde que se introdujese Knowledge Graph, Google no ha dejado de añadir mejoras, más carteles, mejor información… En el KeyNote se desveló que como era de esperar Google Search había vuelto a sufrr algunas modificaciones. En primer lugar se dijo que se había extendido el repertorio de idiomas con acceso a Knowledge Grapah, siento ya el total de idiomas soportados un total de 13: Ingles, Frances, Italiano, Español, Aleman, Japones, Portugues, Ruso, Koreano, Polaco,Turko, Chino simplificado y tradicional

Igualmente, se añadieron datos y gráficas de poblaciones, la posibilidad de buscar dentro de nuestro propio contenido en Google+ como fotos y otros o acceder a información de nuestros propios correos electrónicos. Hace poco también se añadió la posibilidad de identificar la canción que estaba sonando, al más puro estilo SoundHound.

Google Now por su parte, se perfilaba como una tecnología que predice lo que vas a hacer, o al menos potencialmente podrías hacer. De nuevo, Google no ha dejado de añadir mejoras cada día, y lo que antes se limitaba a conocer el tiempo, la bolsa o algunas efemérides concretas, a día de hoy Google Now te predice donde quieres comer, que transporte tomar, que tráfico te encontrarás camino a donde sea que vayas, el tiempo que hará… y a todo ello ahora también será capaz de predecir los viajes contratados que tengas (gracias al correo electrónico), películas de interés, libros… Es cierto que este sistema es infinitamente mejor e integrado en Estados Unidos, pero es cierto que en los últimos meses han sido muchas las mejoras que hemos encontrado aquí también en España

Desde el KeyNote, Google Now también acepta recordatorios que pueden añadirse de forma sencilla.

Como última novedad, se hizo público por fin la inclusión de Google Search mediante voz dentro de Chrome y Google. Esto permitirá simplemente con un micrófono buscar por todo Internet. Google ha bautizado esto como modo conversacional, aunque en realidad el navegador no responderá como una conversación, sino que mostrará la información que se le solicite. En el Keynote se vio de ejemplo lo simple que resultaba buscar incluso dentro de las imágenes propias de Google+, ver el vuelo contratado… eso sí, por ahora tan solo en Estados Unidos.

 

 Samsung Galaxy S4

Muchos fueron (yo el primero), que pensó que Google añadiría algún nuevo dispositivo Nexus, o al menos alguna nueva versión de alguno de ellos, pero no fue así. En cambio, y por sorpresa un poco de todos, anunció que pasarían a vender ellos (además de Samsung) el Galaxy S4, aunque una versión modificada de este. ¿Modificada? Sí, al estilo Nexus

Para empezar, será comprado a través de Play Store (al menos en Estados Unidos), completamente libre y con el Bootloader desbloqueado igualmente. Lo más importante es que tendrá instalado el software nativo de Google! Nada de las pieles personalizadas de los fabricantes, el sistema operativo sin más tonterías, y por supuesto con las actualizaciones puntuales de la mano de Google. Se servirá la versión LTE de este, con 16GB.

No es una mala alternativa, pero lo peor desde mi punto de vista es el precio, 649$. Sinceramente me parece muy caro, si tenemos en cuenta el precio del gran Nexus 4, que es menos de la mitad, 300$. Por supuesto que el Galaxy S4 es posiblemente ahora mismo el mejor terminal del mercado, no lo discuto, pero aun así creo que a cualquier persona le compensaría más tener dos Nexus 4 antes que un Galaxy S4. Al menos, es mi opinión por supuesto. Aun así aplaudo el gesto de Google, y solo espero que otros fabricantes tomen ejemplo y dejen de personalizar tanto los dispositivos, o al menos ofrezcan una alternativa de sus teléfonos de gama alta con el software nativo de Google sin añadiduras. Estará disponible a partir del 26 de Junio, y es muy posible que Google extienda su comercialización a otros países.

s4

Google I/O 2013

Aunque sin mucho tiempo para escribir últimamente, saco unos minutos para recordar a todos que a las 18.00 peninsular será el comienzo del KeyNote de GOogle I/O de Este año. Para quien ande despistado, el Google I/O es la conferencia anual de Google más importante, durante 2-3 días se darán conferencias, charlas, coloquios, talleres y otros sobre prácticamente la totalidad de los productos de Google… sin contar por supuesto lo que la mayoría le resulta de más interés, las novedades que nos trae Google.

A Google no le guste adelantar nada, pero el que mas o el que menos especula sobre «lo nuevo» que nos descubrirá google en el Keynote (recordemos que dura unas 3 horas). En realidad no son pocas las novedades que yo personalmente apuesto a que darán el pistoletazo, por supuesto algunas de ellas ya medio confirmadas, aunque repito, son solo mis apuestas:

 

Android:

-Android 4.3
-Nexus 7 con el hardware mejorado
-Nexus 10 HDSPA/LTE
-Nexus 4 LTE?
-Babel: Sería la integración final de mensajería de Google+ y Google Talk?

Google+

-Babel
-Google+ API para desarrolladores
-Google Sign-on más cercano para todos

Gmail

-Integración del espacio de Correo con Drive: En vez de tener 20GB para Gmail y 5 para Drive/imágenes, 25 compartido para todo
-Babel

Maps

-Nueva versión web totalmente remodelada como ya ha podido verse en muchas imágenes
-Mejora sustancial en los algoritmos de búsquedas
-Integración con la información recopilada por Android de los lugares más visitados o realizados el ckeckin
-Actualización también de Maps para Android?

Music

-Servicio Streaming de pago anual/mensual tipo Spotify
-Incremento en el repertorio de discográficas y de Países

Google Play

-Nueva plataforma específica para juegos

 Google Glass

-Precio definitivo y fecha de comercialización

 

Por supuesto son solo especulaciones, pero lo cierto es que bien o mal dentro de menos de una hora comenzará el Keynote. Personalmente dudo que puedan superar el espectáculo que dieron el año pasado. Este año veremos…

Comparativa Navegadores 2012/Q2: Internet Explorer 10, Firefox 20.0, Chrome 25.0, Safari 6, Opera 12.12

Índice

  • Navegadores
  • Condiciones de las pruebas
  • Benchmarks
  • Conclusiones

 

Versiones de los navegadores

 

Navegadores:

 

Aunque hayan pasado más de 6 meses, no podía faltar una nueva entrega, sobre todo teniendo en cuenta que no hace mucho Windows 8 fue oficialmente lanzado, y con él por tanto la versión final de Internet Explorer 10. La razón por la cual siempre hago mis comparativas con las versiones aun en desarrollo la he dicho siempre y siguen siendo las mismas, y me limito a hacer prácticamente un Copy/Paste de la comparativa anterior:

a) Chrome y Firefox poseen ciclos de actualizaciones muy rápidos, haciendo por tanto que estos siempre tengan ventajas ante otro tipo de comparativas que los enfrenten ante navegadores con ciclos de actualizaciones más largos como Opera, IE o Safari, ya que estos últimos tan solo lanzan versiones oficiales cada bastante más tiempo. Comparar las últimas versiones en desarrollo de cada navegador nos permite ser más imparciales. Incluso Microsoft está empezando a lanzar cada cierto tiempo versiones preview.

b) Los amantes del software (geeks y nerds entre otros) siempre deseamos probar y tener a mano lo último que se está cociendo, cambios que verán la luz de forma oficial para todo el público dentro de quizás unas semanas, unos meses o incluso un año. Por tanto es también una buena oportunidad para probar no lo que hay sino lo que tendremos.

 

Por tanto como es costumbre, tanto Firefox como Chrome se han tomando sus respectivas versiones Nighly. Opera no lanza versiones Nighly, pero sí prácticamente  todas las semanas, al igual que Safari. Las versiones de todos ellos se han especificado anteriormente. Para Internet Explorer se ha usado la versión más actual a la que tenemos acceso, que aunque no es una versión en desarrollo, no olvidemos que su lanzamiento oficial conjuntamente a Windows 8 hace tan solo unos días, puesto que por desgracia no tenemos acceso a versiones betas o alpha.

Como siempre, las versiones de 64 bits de Opera, Internet Explorer y Firefox NO CONTARÁN en el tanteo final, y tan solo tendrán un valor presencial en las comparaciones pertinentes, exceptuando en las de compatibilidades con estándares puesto sus resultados serían supuestamente los mismos. Esto es necesario debido a que lamentablemente aun no tenemos disponible versiones de 64 bits de Chrome o de Safari. Hay que anotar que aunque Windows 8 x64 incorpora tanto una versión de 32bits como de 64bits, el navegador siempre ejecutará una instancia en 64bits que tomará el rol de la interfaz, mientras que ejecutará el contenido de las pestañas en instancias separadas, de 32bits si se ejecuta en modo estándar Internet Explorer, o en el modo «puro» de 64 bits si se habilita las funciones de «Modo protegido Avanzado». En las pruebas de 32 bits se usa el modo mixto (la interfaz siempre se ejecuta con instancias de 64 bits), en las de 64 bits se activa el modo protegido avanzado y todo se ejecuta en 64bits.

Por quinta (y posiblemente última vez), la versión de Safari instalada está exenta de QuickTime como ya se ha explicado otras veces, esto hace que pierda muchos aspectos de compatibilidad. Las razones son las que he dado siempre, QT actúa de plugin para Safari para dotarlo de mayores prestaciones, y la idea es probar siempre los navegadores, no sus complementos. De lo contrario, por esa regla de tres, podríamos instalar diferentes plugins o extensiones a otros navegadores para dotarlos de más características o mejoras. Sería evidentemente injusto. Apple es la que no debería de asociar un reproductor multimedia a su navegador.

Por otro lado, posiblemente esta sea la última vez que veamos Safari en estas comparativas. Es muy simple. Aunque Apple no ha hecho hasta la fecha ningún comunicado al respecto, lo cierto es que desde hace ya meses Apple ha eliminado de su web todo comentario, enlace, propaganda… hacia Safari para Windows. Esto no es algo a extrañar realmente, si tenemos en cuenta que el índice de mercado que posee Safari en Windows es prácticamente nulo, e incluso en MAC OS ha dejado de ser la opción predominante. Actualmente se siguen generando no obstante Nighlys casi a diario de Safari para Windows desde el proyecto WebKit, lo cual por tanto no debería de ser un problema continuar dando soporte a este navegador en mis comparativas, pero lo cierto es que estas Build no funcionan de forma totalmente independiente, sino que dependen básicamente de toda la interfaz de Safari y otros. Sin el debido soporte de Safari para Windows, estas versiones serán posiblemente cada vez más inestables, y será cuestión de tiempo que dejen siquiera de generarse. En esta ocasión no han existido mayores problemas, y aunque la build se referencia como Safari 5.2 no hay que engañarse, y os aseguro que se ha usado el código más reciente que posee Safari. Por tanto aunque a efectos teóricos se base sobre Safari 5.2, se estará probando Safari 6+

Por último, respondiendo a algunos comentarios y sugerencias de otras veces, la razón por la cual no se incluyen en la comparativa otros sistemas operativos es muy simple. Si quieres hacer una comparativa que sea mínimamente rigurosa tienes que intentar eliminar todas las variables que sean externas a los navegadores. En una comparativa puedes medir al mismo tiempo una sola variable, no dos. Si introdujésemos en esta comparativa resultados provenientes de Linux por ejemplo, además de tener disponibles menos navegadores no podríamos comparar los resultados obtenidos en Windows con los obtenidos en Linux, no tendrían validez alguna puesto que el sistema operativo sería siempre una variable constante. Es como si queremos comparar el rendimiento de una CPU, y para ello tenemos dos equipos totalmente iguales en el que en uno ejecutamos el programa A y en el otro el programa B para medir el rendimiento. Evidentemente ese test no tiene sentido alguno ya que se está midiendo algo de dos formas diferentes. Siempre que sea posible hay que hacer el esfuerzo de no alterar las condiciones, y es por ello que es necesario realizarlo tan solo sobre un solo OS. Sí, se podría hacer la misma comparativa sobre Linux y ver los resultados, y podríamos llegar a conclusiones similares incluso, pero serían solo válidas para ese OS. Dado que Windows posee una cuota de mercado que roza el 90%, es evidente el motivo de por qué se usa este Sistema Operativo.

 

 

Condiciones de las Pruebas

 

Sistema:

  • OS: Windows 8 Enterprise x64
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 310.61)
  • Resolución: 1920 x 1080 (navegador siempre maximizado)
  • Flash Player: 11.5.502 (Firefox, Opera y Safari), 11.3.376.12 (Internet Explorer 7), 11.5.31.106 (Chrome)

 

Como es costumbre, todos los navegadores son instalados de forma limpia en el mismo equipo, usando para ellos como es de esperar perfiles nuevos, tocando mínimamente las opciones de configuración de los navegadores, como pueda ser la página de inicio, la deshabilitación de la carga selectiva progresiva de pestañas, la activación de aceleración por Hardware y WebGL en Opera y poco más. Esto último es debido a que Opera aun no está entregando su navegador con dicho soporte activado, aunque pueda parecer algo de «trampas» se tomará en cuenta también a la hora de evaluar el navegador.

Tan solo se ha instalado como complementos Adobe Flash Player en todos los navegadores y el complemento para WebM de Internet Explorer. El uso de Flash Player es evidente, necesario para algunos test en los que se desea probar el rendimiento Flash en diferentes navegadores y circunstancias, pero también para compararlo con las funciones nativas de vídeo en HTML5. La instalación por otro lado de WebM en Internet Explorer 10 tiene también su lógica. El futuro HTML5 especifica que los navegadores puedan reproducir vídeo sin necesidad de complementos, pero no estandariza que codecs para hacerlo. Opera, Firefox o Chrome soportan todos ellos el estándar propuesto por Google WebM, mientras que Microsoft y Apple apuestan (al menos por ahora) tan solo por H264. Guerras a parte, la idea no es comparar H264 frente a WebM, sino medir el rendimiento de la tecnología de vídeo para HTML5 y compararla a la tecnología de vídeo de Flash. Todos ellos (excepto Safari) soportan de un modo u otro esta tecnología sin ningún tipo de complemento, por tanto el requerimiento mínimo lo cumplen. Ahora bien, como deseamos medir el rendimiento es necesario que TODOS usen la misma tecnología. Por suerte además, existe un complemento oficial del proyecto WebM para IE, con lo que de este modo podemos hacer uso de la tecnología de vídeo WebM de HTML5 en todos los navegadores por igual, excepto como digo Safari, que queda fuera por la sencilla razón que ni siquiera (fuera de la caja) es compatible sin QuickTime. Si Safari fuese compatible al menos con WebM o HTML5 sin necesidad de QuickTime aun podríamos pensar en incluirlo, pero de lo contrario debe de quedar fuera.

 

Cada test se ejecuta 10 veces en cada navegador. Dado que hay test que son muy dependientes a las condiciones externas (y por tanto capaces de generar resultados extraños), el valor final de cada prueba se ha obtenido calculando la media aritmética de los valores registrados un UNA VEZ han sido descartados los valores «extraños» estadísticamente (por medio de la «Distribución Normal»). De este modo se intenta que los datos obtenidos sean lo más fiables posible, sobre todo como he dicho en aquellos test en los que simplemente una pequeña interferencia en el PC como un acceso a disco por algún proceso de fondo, es suficiente para modificar por completo un resultado.

Cada prueba puntúa de 1 a 5 (1 el peor resultado, 5 el mejor), reservando el cero para aquellas pruebas en las que el navegador no pueda realizarse por carencias de este o simplemente produzca un fallo del navegador y sea incapaz de terminar la prueba. En caso de que dos navegadores obtengan el mismo resultado, a los dos se le asignará la misma puntuación, dejando la puntuación restante simplemente sin asignar. Dado que son versiones inestables (al menos algunas ellas) se creará un último «test» que recogerá a modo de resultado la estabilidad del navegador frente a las diferentes pruebas.

 

 

Benchmarks

En esta ocasión no ha habido grandes cambios en los test usados. Si cabe destacar que de momento se ha eliminado de forma temporal el test de PeaceKeeper. La última actualización que hicieron provocó que fuese imposible acceder de forma simple a los resultados parciales, así como no ha sido actualizado algunos de los test que ejecuta a los últimos estándares, con lo que los resultados no son para nada exactos. En cuanto los solucionen, se volverá a incluir.

Las Webs usadas para el consumo de RAM en este caso, así como los tiempos de inicio en frío/caliente y cierre serán las siguientes:

Bandeja de Gmail, Bandeja de Mail Live (Outlook), La página personal de Facebook, La página personal de Google+, YouTube (http://www.youtube.com/watch?v=KEIdACFBhGE en 360p), Portada de «MARCA», Portada de «El País», Google Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser), eBay (http://www.ebay.com/fashion/womens-clothing). Para los test de 20 pestañas, simplemente se han duplicado las 10 anteriores.

 

Test:

  • Rendimiento
    • Tiempo de Inicio en frío (1, 10 y 20 pestañas)
    • Tiempo de Inicio en caliente (1, 10 y 20 pestañas)
    • Tiempo de Cierre (20 pestañas)
    • Velocidad de carga de Webs con/sin Caché
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido 1080p (Flash y WebM)

 

 

 

 

 

 

 

 

Tiempo de Inicio en Frío y en Caliente

Comenzamos con los tiempos de inicio del navegador para 1, 10 y 20 pestañas, siempre a caché vacío. Fundamentalmente, no se trata de medir la velocidad de carga de las páginas (que se verá más adelante), sino el tiempo de arranque y carga del navegador ante los 3 supuestos anteriores. Inicio en fío significa que el PC no tiene cacheado en RAM nada, generalmente se realiza ejecutando el navegador una vez el arranque del sistema se estabiliza y se ejecuta pro primera vez este, restaurando la sesión de forma automática (de 1, 10 o 20 pestañas). En esta ocasión no se ha recurrido al sistema de siempre de reiniciar el equipo para vaciar la RAM, sino una aproximación similar más consistente y más rápida. El inicio en Frío se hace para asegurarnos que no hay datos en RAM que puedan agilizar la carga del navegador, pero el propio sistema operativo hace esto de forma automática nada más arrancar, cacheando en RAM librerías y otros de programas que ejecutamos de forma habitual para que después se ejecuten estos de forma más veloz. A esto Microsoft lo llama por ejemplo «Superfetch». Es decir, que los tiempos de inicio en frío de los navegadores en Windows dependen completamente de esta tecnología. Para evitar esto en lo posible se podría deshabilitar Superfetch (que desestabilizará en parte el sistema) u optar por una opción más simple y eficaz: Llenar la RAM.

El sistema después de un arranque en frío empieza a cachear algunos datos. Si además abrimos cualquier aplicación y la cerramos, una gran parte de la memoria se va llenando con datos antiguos que pueden ser usados a posteriori, esta es la razón por la cual abrir una aplicación la primera vez después de arrancar es más lenta que la segunda. Esto lo hace el sistema pero siempre que existan RAM para hacerlo, a fin de cuentas si el sistema posee RAM que no está usando de forma activa, ¿por qué no usarla para cachear datos? Una forma rápida y totalmente eficaz de inducir a un navegador o cualquier aplicación a un inicio en frío es simplemente colapsando la propia RAM del sistema, obligando a este a consumir todo ese espacio que se había reservado para el caché de las aplicaciones. Esto es fácil, tan solo hay que escribir una pequeña aplicación que nos permita reservar la cantidad de RAM que especifiquemos. Si dispongo de 6GB de RAM libres, de los cuales se usan 2 para caché (y contienen datos), si ejecuto mi aplicación y digo que reserve 6GB más, los 2GB reservados son consumidos, puesto que tiene preferencia la aplicación activa. Crear una aplicación para esto es muy simple, y gracias la propio administrador de tareas de Windows 8 podemos ver en todo momento no solo la RAM libre/consumida, sino también la RAM usada en cada momento en el cacheo de aplicaciones/procesos.

Resumiendo, Inicio en frio en esta ocasión se ha realizado consumiendo toda la RAM del sistema asignada para caché, liberando toda la RAM asignada a la aplicación de consumo (lo que asegura que no hay cacheado nada importante) y ejecutando el navegador. Después de comprar este sistema con el inicio en frío (reiniciar) de toda la vida, los resultados son bastantes consistentes, más exactos y además no requiere reiniciar el sistema.

Inicio en caliente implica por el contrario que el sistema ya ha abierto anteriormente el navegador y ha estado trabajando con él, y por tanto mantiene en RAM mucha de la carga anterior. El tiempo es medido desde que se ejecuta el navegador hasta que todas las pestañas han terminado de cargarse (que no quiere decir que todo el contenido en ellas se haya descargado):

 

[singlepic id=36 w=350 h=228 float=left][singlepic id=35 w=350 h=228 float=center]

  • Chrome: Falló en la carga de algunas pestañas, siendo necesario refrescarlas posteriormente (no se contabilizó ese tiempo extra)
  • Internet Explorer: Múltiples bloqueos y cierres en la carga

 

Tiempo de Cierre

Se ha medido el tiempo de respuesta del navegador a cerrar. En teoría podríamos pensar que estos tiempos son prácticamente inmediatos, pero no lo son. En muchas ocasiones el navegador se mantiene como proceso de fondo durante un largo período de tiempo, lo cual evidentemente no es deseable, sin contar con el consumo de RAM que mantiene. Los tiempos medidos son con 20 pestañas cargadas en los navegadores, contabilizando desde el momento en el que se envía la señal kill al proceso padre, hasta que el árbol de procesos de este es totalmente finalizado, incluyendo el proceso padre evidentemente. Es importante al hablar de proceso «padre» si tenemos en cuenta que navegadores como Chrome o Internet Explorer son multiprocesos, y cada proceso padre ejecuta uno o varios procesos hijos:

[singlepic id=31 w=700 h=456 float=center]

  • Internet Explorer: Grandes irregularidades al cerrearse, diferencias de tiempo…

 

Velocidad de Carga de la Web con y sin caché

Este test posee un doble propósito. Por un lado medir la velocidad con la que los navegadores son capaces de descargar por completo la Web desde los servidores externos, y por otro lado medir la eficiencia del Caché de estos, realizando el test con el caché del navegador activado y deshabilitado. Hay que tener en cuenta que lo que se mide no es el tiempo que tarda el navegador en comenzar a mostrar las páginas o cargarlas por completo, sino el tiempo que tarda el navegador en descargar y preparar TODOS los recursos de las web solicitadas. Es de esperar por tanto que los tiempos en las páginas con el contenido cacheado sea mucho menor. Cada Web (La de Facebook, la d PlayStore, la de Wikipedia y la de eBay) fue abierta de forma aislada y se sumaron los tiempos de todas ellas. Como medida y para la consistencia de los datos, se seguro que el tamaño total de la web era aproximadamente siempre el mismo, y las webs tomadas eran las que presentaban un menor contenido dinámico (invariante):

[singlepic id=30 w=700 h=456 float=center]

 

Consumo de RAM

A día de hoy la gran mayoría de los sistemas actuales cuentan con cantidades más que suficientes de RAM, pero no por ello hay que malgastarlo. Además, hay que entender que cada dato que es cargado en RAM o procede del mismo proceso que lo genera o ha sido cargado desde el disco duro anteriormente, y los discos duros (ya sean SSD o convencionales) siguen siendo con diferencia el elemento más lento del equipo, con lo que esto es de vital importancia. El problema se acrecenta en dispositivos portátiles donde la RAM a veces no es tan «sobrante», o cuando se está trabajando con otras aplicaciones más pesadas. Los datos mostrados corresponden a la memoria Privada usada por el/los procesos, eso quiere decir que no es exactamente el 100% de la memoria RAM ocupada, ya que no se incluyen pequeños «pedazos» adicionales como por ejemplo el mapeo de archivos adicionales como puedan ser las fuentes, archivos de configuración… No obstante, esta «Memoria Privada» supone una precisión de más del 95%, haciendo que sea más que suficiente para nuestros propósitos:

[singlepic id=42 w=700 h=456 float=center]

  • Safari: Múltiples cierres
  • Opera: Picos entorno al 16-20% de uso del procesador
  • Internet Explorer: Picos entorno al 40-50% dele procesador

 

Reproducción a 1080p

Es evidente que la reproducción de vídeo es crucial en los tiempos que corren en la web, un mundo que busca cada vez más el máximo rendimiento con el mínimo consumo posible, lo que alarga las baterías de los dispositivos portátiles también si tenemos en cuenta que la la reproducción de Vídeo continúa a día de hoy siendo uno de los mayores «comecome» de baterías… sin contar con que la gran mayoría del tráfico producido en inet es por estos. La comparativa es doble, ya que no solo compararemos la eficiencia en la reproducción de un vídeo Full HD a través de Flash, sino que también a través del estándar HTML5 vídeo, usando como sistema WebM. Así podremos comparar a grandes rasgos la eficiencia de un sistema o de otro. Internet Explorer reproducirá WebM a través de un complemento como ya dijimos, más que nada porque IE10 oficialmente posee soporte para el estándar de vídeo de HTML5, lo único que ellos ofrecen de base tan solo el uso de H264 y no WebM. El vídeo reproducido en este caso es el mismo tanto en Flash a 1080 como en WebM a 1080 también, el trailer de «El Hobbit«, lo bueno de este vídeo es que está disponible en Full HD tanto en Flash, en WebM como en H264 (aunque este último no lo vamos a testear)

[singlepic id=50 w=700 h=456 float=center]

  • Opera: Saltos tanto en WebM como en Flash, posiblemente algún tipo de FrameSkip

 

SunSpider, V8 y Kraken

Son los 3 benchmarks más utilizados para medir el rendimiento de los motores JavaScript de los navegadores. En los últimos meses Google ha lanzado otro test nuevo a fin de sustituir básicamente V8, llamado Octane. Me parecería injusto usar los dos de Google, por tanto he optado por usar por última vez V8, y en la siguiente será sustituido por Optane. No obstante, aunque los resultados no los publique, son muy similares a los obtenidos por V8, quedando todos los navegadores más o menos en la misa posición parcial.

Como ya he dicho en muchas ocasiones no soy fan de test sintéticos de ningún tipo, y mucho menos tests que han sido optimizados al máximo por todos los navegadores para obtener buenas puntuaciones. Estos 3 test se toman como estándar por todos los navegadores, lo que quiere decir que puedo asegurar que TODOS los navegadores hacen trampas en estos test según les convenga. No quiere decir que sean totalmente inútiles, ya que muchas optimizaciones son llevadas después a los entornos reales, pero por regla general no son demasiado fiables. Así es previsible que Google obtenga un resultado favorable además en V8, Firefox en Kraken y Safari en SunSpider, más que nada porque los test son suyos.

Más adelante veremos que el rendimiento JS en entornos reales (aplicaciones, código…) que a fin de cuenta son muy dependientes de JavaScript, los resultados son muchas veces totalmente dispares a los test sintéticos:

[singlepic id=46 w=350 h=228 float=left][singlepic id=49 w=350 h=228 float=center]

[singlepic id=37 w=350 h=228 float=center]

 

Normal Mapped, Canvas Performance, VII y Asteroids

HTML5 permite integrar dentro del navegador de forma simple contenidos complejos a través de canvas. Básicamente Canvas define un marco de ejecución de cierto contenido (generado principalmente por JavaScript). Es por ello que en realidad podría verse Canvas como la aplicación práctica del uso pesado de JavaScript. Esto ha permitido suprimir la necesidad de complementos para un gran sin fin de necesidades, con lo que tan solo con disponer de un navegador compatible podemos hacer correr la aplicación sin importar nada más… siempre que por supuesto el navegador sea capaz de ejecutar en tiempo real la aplicación correspondiente, lo cual como digo se fundamenta en JavaScript

Normal Mapped es un test que aunque es claramente gráfico posee una carga de está mínima, siendo el mayor aporte JS, y por ello queda relegado a este grupo de test. Por otro lado, Canvas Performance, es un benchmark muy interesante de cara a que trata de medir el rendimiento no de JavaScript en realidad, sino del contenido ejecutado en Canvas de forma sintética, al más puro estilo de los test sintéticos JavaScript. VII es una demo de un juego creado a modo de test para los navegadores que hace un uso bastante extenso no solo de JavaScript, en este caso de CSS, SVG y de la composición de capas. Asteroids por otro lado es un test ya conocido, con fuerte dependencia JavaScript:

[singlepic id=39 w=350 h=228 float=left][singlepic id=29 w=350 h=228 float=center]

[singlepic id=51 w=359 h=235 float=left][singlepic id=28 w=359 h=235 float=center]

  • Opera: En Canvas usa algún tipo de FrameSkip, lo cualmejora la puntuación pero produce saltos constantes

 

Tanque de peces (3.000 peces), Pecera (2.000 Peces)

Lo bueno de los peces, es que solo tenemos que añadir más al tanque o a la pecera para aumentar la complejidad. Se han mantenido los 3000 peces en el tanque y los 2000 en la pecera, aunque en esta última ya se ha alcanzado el tope por dos de los navegadores (se incrementará en la próxima). Dos Test similares pero diferentes, orientados ambos al rendimiento gráfico de Canvas puro y duro. Los dos fueron diseñados para aprovecharse de la aceleración hardware de contenido, por lo que es de esperar que Safari fracase estrepitosamente.

Todos los test con fuerte contenido gráfico acompañan igualmente la carga en la CPU y en la GPU, lo cual servirá además para comparar el consumo energético de cada navegador

[singlepic id=48 w=350 h=228 float=left][singlepic id=40 w=350 h=228 float=center]

 

«Come-Cocos» (Browse Hunt)

Un test bastante exigente en todos los aspectos, aunque está en la categoría de gráficos hace un uso extensivo de JS y SVG.  sin duda caprichoso y que prácticamente ningún navegador logra ejecutar de forma correcta, después de muchos meses ninguno es capaz de llegar a los 60 fps.

[singlepic id=32 w=700 h=456 float=center]

 

«Letras» (SpeedReading)

Uno de los mejores test para comprender la importancia de la aceleración gráfica dentro de los navegadores. Pasamos de los 6 segundos en finalizar el test a más de 2500 en el caso de Safari. Posiblemente sea también la última vez que lo veamos en acción, puesto que exceptuando Safari el resto de los navegadores logran «Pasarlo» correctamente, de 6 a 7 segundos no es algo que podamos… «valorar» en demasía.

[singlepic id=44 w=700 h=456 float=center]

 

Psicodélico

Otro test que se ha hecho muy extendido y famoso en toda la red por demostrar el potencial gráfico actual de los navegadores. Existen varias versiones de este test, pero al final siempre es lo mismo: Una imagen que gira sobre si misma a la máxima velocidad posible. A diferencia que el test anterior, es uno de los mejores test para ir comprobando la evolución y el perfeccionamiento del potencial gráfico del navegador:

[singlepic id=41 w=700 h=456 float=center]

 

Webvizbench

Aunque no deja de ser un benchmark, es uno de los mejores ejemplos de canvas compuesto, con una alta carga JavaScript, gráfica, CSS… explota al máximo desde transiciones, composición de capas, animaciones… es de los test más completos que veremos por aqui, y orientado siempre a aplicaciones prácticas que podrían/pueden crearse y que antes eran totalmente impensables. Uno de mis test favoritos:

[singlepic id=53 w=700 h=456 float=center]

 

Tanque de Peces (50.000) y Sistema Solar (4000 planetas), ambos para WebGL

De nuevo, dado que todos los navegadores exceptuando inexplicablemente Internet Explorer 10 y (previsiblemente) Safari soportan WebGL, es ya de obligado cumplimiento su testeo. En realidad Safari si cuenta en esencia con soporte para WebGL, pero este soporte es tan solo para MACOS, por tanto queda exlucído a última posición junto a IE10.

El caso de Microsoft de no dar soporte para WebGL fue explicado hace tiempo por ellos mismos, personalmente no comparto su visión pero es respetable. El problema nace de que puede ser «peligroso» que el navegador pueda tener acceso directo o indirecto al hardware del equipo, como es en este caso el adaptador de vídeo para poder hacer uso de webGL. Navegadores como Chrome, Firefox u Opera no es que no tengan en cuenta este tipo de «problemas de seguridad potenciales», todo lo contrario, simplemente se centraron en solucionar esas deficiencias. Han pasado ya muchos meses desde que comenzamos a ver WebGL en los navegadores y sabemos por los reportes de seguridad que las primeras versiones que implementaban los navegadores eran como digo potencialmente peligrosas, ya que podría descubrirse (siempre hipotéticamente hablando) un exploit a través de WebGL que a su vez pudiese interactuar con el Driver de vídeo y por ende ejecutar código malicioso en modo Kernel (muy peligroso). Esto se ha ido solucionando con el tiempo, y a día de hoy se usan incluso extensiones de OpenGL específicas como pueda serlo GL_ARB_robustness para protegerse de este tipo de posibles problemas potenciales.

Esto no elimina totalmente el potencial peligro de WebGL, y técnicamente podría encontrarse alguna combinación de shaders,  texturas, geometrías… que desestabilizasen el sistema. En realidad no por un problema del navegador en sí, sino por el propio Driver de vídeo del sistema o una mezcla de ambas cosas. Es un riesgo mínimo y hay sistemas como digo para evitarlo (para empezar unos Drivers actualizados siempre ayuda). Por otro lado hay que destacar que aunque GL_ARB_robustness es una solución muy eficaz (y realmente funciona), es una extensión de OpenGL 3.2, lo que deja fuera prácticamente por diseño a cualquier navegador bajo MAC OS (el soporte de OpenGL bajo MACOS es de muy deficiente a pésimo) y a muchos adaptadores (sino todos) de AMD. Tan solo nVidia y bajo Windows se salvan en gran medida, con lo que se puede comprender en parte el miedo de Microsoft. Repito… hablamos hipotéticamente.

 Es interesante no obstante como los chicos de Mozilla tomaron el test original de Microsoft del tanque de peces (usado anteriormente con 3000 peces) y lo adaptaron a WebGL. Comprobamos como tenemos que elevar a la friolera de 50.000 peces para no alcanzar los 60 fps de tope. Si bajo la aceleración por Hardware por contenido y capas 3.000 peces parecían ser el tope por ahora, el rendimiento por WebGL frente al test anterior es sorprendente:

[singlepic id=47 w=350 h=228 float=left][singlepic id=43 w=350 h=228 float=center]

  • Opera: No es capaz de representar los «planetas» en Sistema Solar

 

Spinnig Balls

Cualquier programa informático generalmente requiere un buen gestor de memoria que esté de forma asidua buscando y liberando cualquier trozo de RAM que ya no use. Esto es útil por dos razones principalmente: Primero porque de lo contrario el consumo de RAM subiría constantemente y terminaría con consumir toda la existente, y segundo porque la ejecución del programa sería cada vez más lenta y los datos en RAM más fraccionados. Esto como digo se evita «reciclando» la RAM cada cortos períodos de tiempo, función que es llevada acabo por lo que llamamos un Garbage Collector (recolector de basura en sentido literal). Los navegadores no son una excepción a esto, y pueden producir en cortos períodos de tiempo muchos objetos nuevos debido a código JavaScript o DOM, los cuales muchos de ellos incluso son destruidos con la misma rapidez. Esto genera constantemente muchos trozos de RAM «basura» que es bueno… es necesario ir liberando. La alternativa de no usar GC (Garbage Collection) no es viable en ninguna circunstancia, sin esto el navegador no tardaría en colapsarse y agotar la RAM del sistema.

El problema de los recicladores es que son funciones/subrutinas que tienen que ser ejecutadas como es natural dentro de los propios procesos, y dependiendo del sistema GC que estén usando pueden incluso detener la ejecución del proceso por completo hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo como una extrañas pausas en un momento dado, un salto en u juego, un drop de FPS momentáneo… cuestiones que realmente no implican que el proceso se ejecute más rápido o menos rápido, sino que se ejecute de forma fluida o no. Esto lo hemos visto en muchos test en los que algunos navegadores no es que obtengan bajos FPS, sino que aplicaciones que aun obteniendo altos FPS son totalmente imposibles de manejar dada las continuadas pausas.

Cualquiera que haya jugado a cualquier juego online conoce los efectos del «lag», pues bien esto sería algo similar, donde da igual cuan potente sea el equipo, puesto si el lag es alto puedes darte por muerto. La eficiencia o no de cada modelo de GC varía. En algunos programas puede ser mejor un modelo, en otros otro. Por ejemplo se podría hacer un GC simple que cada 2 segundos ejecutase una subrutina para hacer el reciclado, pero el tiempo invertido en ese «limpiado» también variará en función de la última vez que se realizó. Podríamos ejecutar GC cada X segundos, pero cada esos X segundos casi con toda seguridad se notaría una micro pausa. Si no se ejecutase ya sabríamos que pasaría y si se  hiciese cada medio segundo a lo mejor se estaría tb produciendo una latencia y lag por el número de veces que se ejecuta el recolector… es decir, no es nada fácil dar con el mejor sistema, puesto que el mejor sistema depende de cada momento.

Este test mide este comportamiento. Genera muchos objetos a gran velocidad constantemente, y mide las pausas que se registran. Este test es muy muy sensible a cualquier otro proceso que se esté ejecutando, incluso puede afectar el movimiento del propio ratón, así que ojo. Cada pausa que registra el programa la anota, y la mejor puntuación es para aquel navegador que realiza menos pausas o pausas más cortas. Es decir que un navegador que a lo mejor tienen 10 pausas de 5 ms y otro que posee 5 de 10 ms, el primero obtendrá mejor resultado ya que la implicación es menor y la ejecución mucho más fluida.

[singlepic id=45 w=700 h=456 float=center]

 

Test de compatibilidad HTML5 de Niels

A día de hoy un buen navegador no solo es aquel que es el más rápido, sino que también está en continuo desarrollo para adaptarse a los nuevos tiempos y a los nuevos estándares. El test de Niels es uno de los mejores identificativos para medir la compatibilidad con el futuro estándar HTML5. En las últimas actualizaciones se le ha añadido también algunas otras características ajenas a HTML5 de todos modos. Hay que tener en cuenta que este test al margen de algunos otros añadidos y HTML5 no testea otros estándares igualmente importantes, como puedan ser WebGL, CSS, SVG…

[singlepic id=38 w=700 h=456 float=center]

  • El test de Niels se basa actualmente sobre 500 puntos máximos.

 

Test de compatibilidad WebGL de Khronos

Exactamente igual que testeamos poco a poco las especificaciones HTML5 que van formándose, hacemos lo mismo con las especificaciones de WebGL. WebGL es un estándar para permitir que el navegador pueda ejecutar gráficos avanzados en él, es llevar la API OpenGL a los navegadores. Dos navegadores pueden ser compatibles con WebGL, pero si uno no es compatible en algunas cuestiones de WebGL el resultado puede ser simplemente que el contenido no se visualice o se visualice mal. Mientras buscaba algunos test WebGL interesantes, en muchos casos no todos los navegadores con soporte WebGL podrían ejecutarlos correctamente

[singlepic id=52 w=700 h=456 float=center]

  • Internet Explorer y Safari: No son compatibles
  • Opera: Aunque es compatible, múltiples test provocan cierres constantes

 

IE Center Testing

Microsoft posee desde hace ya tiempo un site con una tabla que muestra la compatibilidad de los diferentes navegadores frente a los nuevos estándares. Los test que se han usado aquí son exactamente los mismos, solo que yo los aplico a mis versiones de los navegadores, y no a las que aplica MS.

Hay que entender que aunque la suite de test que expone Microsoft es bastante completa (siendo a mi gusto el test de compatibilidad mas completo que hay), es totalmente parcial y engañosa. La suite de test creados por Microsoft para probar la compatibilidad de los navegadores se basa en exponer TODAS las compatibilidades que Microsoft sabe que Internet Explorer 10 es compatible, con lo que cabe esperar que Internet Explorer 10 obtenga un 100% en todos los test. En cambio, para muchas otras especificaciones y partes de especificaciones en las que Internet Explorer no es capaz de estar a la altura, Microsoft simplemente no crea test para ellos. Es el caso de muchas especificaciones de HTML5 (que es mucho mejor identificativo el test de niels) o para WebGL. A esto habría que sumarle además errores de los propios tests que conscientemente o inconscientemente Microsoft comete, haciendo que IE 10 sea capaz de pasar dichos test y la competencia no. Esto no es tan extraño, pensar que muchas cuestiones de las especificaciones son totalmente interpretativas, y así por ejemplo Mozilla puede entenderlas de un modo y Microsoft de otro. Otras veces simplemente se deja abierto a elección de cada cual como hacerlo… Supongo que la mejor forma de saber quien de ellos tiene razón es mirando simplemente las implementaciones de cada uno, y si 3 lo hacen de un modo y solo es uno quien la interpreta de otro, posiblemente esos 3 tengan razón. De todos modos aquí nos basamos tan solo en los test de Microsoft tal como ellos los concibieron.

Todo esto se resume con que esta suite es crucial a día de hoy y un excelente trabajo por parte de Microsoft sin duda, pero que quizás tan solo cubre un 60% de un todo, siendo el 60% que cubre el que precisamente interesa a Microsoft por ser compatible con su navegador. Aun así el soporte para CSS, SVG, JavaScript…  es bastante bueno. Quizás la mejor forma de interpretar estos resultados sería eliminando a Internet Explorer de este test, lo que nos daría posibilidad de comparar realmente otros navegadores entre ellos, no contra otro que evidentemente sabemos que va a ganar (se hizo para ello).

[singlepic id=34 w=700 h=456 float=center]

  • Test realizados con la última versión del IE Center de Microsoft, actualizada a 25/10/2012

 

  Test de W3C para CSS 2.1

 Pese al bombo que se le ha dado a las futuras especificaciones de HTML5, posiblemente CSS sean especificaciones mucho más importante que los nuevos añadidos que pueda implementar HTML5. Esto es simple, CSS es usado a día de hoy prácticamente en todas las web del mundo, y cada vez se hace un uso más intensivo de este, tanto para aplicar simples estilos, a crear auténticos efectos de todo tipo.

CSS permite básicamente aplicar estilos, formatos… a cualquier parte de una web, elemento o conjunto de ella de forma que sea simple reutilizar su código, modificarlo… y como cualquier otro estándar ha estado en continuo cambio y evolución. Las especificaciones CSS 2.1 son a día de hoy ya un estándar en uso, no es como HTML5 un estándar en desarrollo, sino que esta por decirlo de algún modo publicado. Es cierto por supuesto que se continúan revisando sus especificaciones añadiendo… pero básicamente está terminado. La evolución de este sería CSS 3.0, que se encontraría en el mismo estado más o menos que HTML5, en pleno desarrollo.

En este caso, me gustaría tener tiempo material para poder lanzar un análisis exhaustivo sobre los navegadores y CSS 2.1 gracias a la suite de W3C, el problema es que hablamos de miles de test y no son automatizados, requieren una constante vigilancia. Es por ello que en esta ocasión he de optar por tomar los datos oficiales de W3C sobre estos datos, y lo que voy a exponer aquí no son pruebas personales y locales, sino los datos del último reporte de W3C. 

Los datos son simples de interpretar, existe un porcentaje de test cubiertos y otro de test cubiertos pasados. Como es porcentual, y teniendo en cuenta que la mayoría de los navegadores tienen cerca del 100% de test cubiertos, podemos usar de resultado final el porcentaje de test pasados cubiertos. Por supuesto este tendrá una pequeña desviación de error, que es menor en tanto y cuanto el porcentaje de test cubiertos sea mayor.

En el futuro intentaré poder pasar manualmente todos los test a cada navegador, puesto que los resultados del W3c no son aplicados a un navegador en particular, sino que se aplican a cada Engine del navegador, y además son acumulativos. Es decir que Safari o Chrome se le asigna el mismo valor (cuando por descontado las puntuaciones serían diferente), y por otro lado no se aplican tan solo a cada versión del navegador en particular, sino en el conjunto de todas ellas. Pese a todo, es interesante tener una visión globgal de la compatibilidad de los navegadores frente a CSS 2.1

Sobre CSS3, el test de Microsoft ya cubre parte de estas especificaciones, y en el futuro incluiré también la suite oficial de W3C de test para CSS3 (muchos de los cuales son los que usa Microsoft)

 [singlepic id=33 w=700 h=456 float=center]

 

 

 

Conclusiones

Si valoramos cada navegador como se dijo al comienzo, los resultados serían por tanto los siguientes:

Resultados Firefox 20 x86 Chrome 25
IE 10 x86
Opera 12.12
Safari 6
Rendimiento 62 41 32 24 35
JavaScript 12 13 11 5 4
Canvas 13 17 14 11 5
Gráficos 28 16 23 20 7
WebGL 10 7 0 7 0
Otros 5 4 1 3 2
Compatibilidad 17 15 12 9 4
Estabilidad 5 4 2 1 4
           
Total 152 117 95 80 61

 

  • Rendimiento

    El rendimiento de un navegador no sólo se resume en lo rápido que pueda ejecutar un código en JavaScript o los fps que sea capaz de mostrar en cualquier aplicación/juego. De echo, desde mi punto de vista posee un peso más que importante a la hora de escoger uno u otro. ¿Cuantas horas a la semana pasamos delante de un PC/dispositivo con el navegador abierto? Cada vez disponemos de dispositivos más potentes, pero las páginas Web, las aplicaciones Web… cada vez son más complejas igualmente y requieren de esa potencia extra. Por tanto es de extrema importancia que el navegador no solo sea capaz de ejecutar una tarea lo más rápida posible, sino que el propio navegador se comporte de forma ágil y veloz en el sistema. Eso implica que tenga excelentes gestores de memorias propios, que pueda gestionar inteligentemente la carga de nuevos contenidos, reducir en la medida de lo posible los accesos a disco, innovar en nuevos sistemas de almacenaje de datos para su rápido acceso, reducir la sobrecarga del propio OS… y sinceramente esto es una tarea muy complicada.

    En cuanto a tiempos de inicio se refiere, en este caso es Firefox quien prevalece sobre el resto casi en todas las pruebas. Esto posee una mayor importancia si recordamos que Firefox no es un navegador multiprocesado como es Chrome, lo que significa que los chicos de Mozilla están aunando un esfuerzo increíble en mejorar la respuesta general del Navegador. Chrome e Internet Explorer aunque son multiprocesados (que no quiere decir multihilos, que lo son todos) no son capaces de optimizar lo suficiente el código para estar a la par, pero exceptuando Opera que posee problemas en este caso, no tienen un rendimiento que sea muy alejado.

    El principal problema de abrir múltiples pestañas a la par es la sobrecarga en el navegador, independientemente de la velocidad con la que se carguen después en el navegador. En los navegadores no multiprocesados como Firefox, Opera o Safari la apertura múltiple de muchas pestañas podría provocar al usuario la sensación de paralización/congelación de este hasta que prácticamente todas las pestañas estuviesen cargadas, ya que desde el punto de vista del navegador tan solo estaría llevando a cabo una misma tarea. Para Internet Explorer o Chrome este problema no lo tienen, cada pestaña tiene su propio espacio y sería el propio sistema operativo quien gestionaría por medio de su planificador (Scheduler). Para tratar con ello, tanto Opera como Firefox usan por defecto la carga selectiva de pestañas, es decir, por defecto cuando se abren múltiples pestañas a la par tan solo se cargan aquella que esté en primer plano. El efecto es inmediato, de poder tener el navegador paralizado durante múltiples segundos la navegación es instantánea, y mientras se pueden ir cargando de fondo el resto de las pestañas. Por supuesto a la hora de medir los tiempos, este comportamiento se deshabilitó para que todos los navegadores estuviesen en igualdad de condiciones, como es natural.

    Todo tiene pros y contras, y que una aplicación sea multiprocesos implica inevitablemente otros efectos secundarios cuando no se cuidan demasiado, y que se evidencia en una sobrecarga adicional en la memoria RAM y en el tiempo necesario para finalizar por completo la aplicación. En esta ocasión Chrome ha mejorado en mucho el cierre del navegador, mientras que IE continúa con tiempos muy altos y muy inestables. De cualquier modo, se puede apreciar perfectamente como precisamente Chrome e IE poseen con diferencia el mayor consumo de RAM, mientras que el resto de los navegadores poseen un consumo mucho más amortiguado, llegando hasta las increíbles cifras de FIrefox. Uso increíbles porque si las comparamos con Chrome, para 10 y 20 pestañas Chrome casi duplica el consumo de RAM frente a Firefox. Tanto Opera como Safari poseen un consumo medio no obstante.

    Respecto a la carga de contenido cacheado y sin este, vemos que de nuevo Firefox vence, aunque prácticamente con unos resultados iguales a Chrome, siendo las diferencias complicadas de apreciar. Safari tampoco queda muy lejos de Chrome, e incluso IE no obtuvo unos resultados demasiado malos, sino fuese por algún que otro problema cuando no cachea el contenido.

    Por último, hay que destacar el rendimiento en la reproducción de contenido en 1080p de los navegadores y de la mitificación que otrora intentó Steve Jobs en que Flash es la lacra para el rendimiento, la seguridad, la batería y el pasado. 6 meses después, volvemos a demostrar que flash sigue siendo la opción más viable, más rápida, con menor consumo energético, con mayor rendimiento para la reproducción de contenido audiovisual. Si miramos los recursos usados por el equipo en la reproducción de contenidos en Flash y contenidos en WebM, vemos que las diferencias son notables, aunque en esta ocasión vemos que los resultados son más moderados, lo cual nos dice que posiblemente nVidia al menos habría aplicado algún tipo de aceleración hardware a sus drivers para WebM, y esto se nota. Aun así vemos que es mucho más eficiente Flash, mientras que reproducir en el equipo de pruebas un vídeo 1080p en flash consumía en el peor de los navegadores un 13% de la CPU (menos de un 1% en los mejores casos) y un 11% la GPU (en el peor de los casos), WebM llegó a necesitar en el peor de los escenarios un 13% CPU/20% GPU. sin duda alguna es una gran evolución desde la última comparativa, pero aun así Flash continúa siendo lider.

    Por supuesto, se podría usar otros codec como H264 para la reproducción de vídeo por HTML5, y este poseería mejor soporte para aceleración por hardware que WebM (y mayor calidad), pero h264 está fuertemente patentado y ya explicamos el por qué de usar WebM.

    Estoy convencido que en el futuro se podrá estandarizar el uso de codecs en los navegadores y que la reproducción por medio de HTML5 será tan eficaz como con Flash, pero eso será el futuro, continúa estando lejos. El proyecto WebM no será posible mientras que el soporte para este sea el que estamos viendo.

     

  • JavaScript

    Los test sintéticos JavaScript que ya conocen todos siguen siendo punto de referencia para muchos. Como ya he dicho tantas veces, me parece que son test tramposos que tan solo buscan la buena prensa de los medios. Seamos sensatos, cualquiera que eche un vistazo a los números y luego a los entornos reales ve que existen diferencias cuanto menos graciosas. Así por ejemplo supuestamente Internet Explorer mantiene la primera posición en SunSpider, pero si miramos en Kraken que es un derivado de SunSpider queda lejos de esa posición.

    No hay que ser un genio para darse cuenta que todos los navegadores (sin excepción) optimizan partes de su código a sabiendas de estos test, con la inclusión de Fast Path y otros. Por supuesto que muchas de estas optimizaciones pueden ser llevadas a entornos reales, pero es evidente que la mayoría no, la mayoría tan solo tienen utilidad en estos test, y por tanto su fiabilidad es más que dudosa.

    De nuevo no quiere decir que sean totalmente inútiles este tipo de test, y se aprende mucho de los motores JS de cada navegador, se pueden detectar puntos calientes en ellos, mejorar… eso por supuesto!! pero estos test tienen sentido realmente cuando se comparan no navegadores Vs navegadores de la competencia, sino en todo caso las mejoras existentes en JavaScript entre las diversas versiones del mismo navegador.

 

  • Canvas

    He querido separar este apartado del de JavaScript, aunque en realidad están muy relacionados uno con otros. Canvas es una de la infinidad de especificaciones que poseerá el estándar HTML5 y que se están empezando a usar muy poco a poco. Como ya he dicho, Canvas define algo así como un espacio de trabajo en el que se ejecutará un código principalmente en JavaScript, CSS… con lo que es posible la creación de aplicaciones Web complejas, y por supuesto juegos como Angry Bird y tantos otros. El rendimiento de estos «marcos» está ligado íntimamente con JavaScript, pero como veremos en el apartado gráfico también de otros muchos factores.

    Es complicado medir este apartado dado que se puede crear un Canvas con el contenido más vario pinto posible, y es más que posible que en algunas aplicaciones domine un navegador y en otras domine otro. Si vemos los resultados son muy variados, no hay un claro ganador porque como digo es muy dependiente del contenido del canvas. Quizás podamos afirmar que cuando Canvas posee un fuerte componente Javascript, el ganador es Opera o Chrome, mientras que si posee un componente gráfico es Firefox.

 

  • Gráficos

    Hay que tener en cuenta antes de empezar, que aunque esta sección se llame «gráficos» no tiene nada que ver con la elavoración de gráficos complejos 3D ni nada por el estilo, sino test que pueden sacar un provecho enorme de la aceleración hardware. Así por ejemplo tenemos el test de SpeedReading que tan solo se vasa en un marcador veloz de letras, o psicodélico, que no deja de ser una imagen girando sobre sí misma.

    Opera continúa por defecto con esta característica deshabilitada, aunque en esta ocasión ha logrado rebajar de forma considerable el uso de GPU que tenía anteriormente. Internet Explorer o Firefox continuan siendo lideres indiscutibles, siendo muy eficaces tanto en uso de GPU como en rendimiento general.

    Tanto Internet Explorer como Firefox usan el mismo Backend usado de forma muy similar, aunque Firefox lo usa por regla general algo mejor (no demasiado). Chrome por su parte hace algo similar que Opera, usando un backend de OpenGL Safari por contrapartida parece haber abandonado el soporte para Windows, con lo que es más que posible que jamás lo tenga. En la versión de MAC OS posee cierto tipo de aceleración, pero recordemos que MAC OS no posee ninguna API Decente de aceleración hardware 2D, con lo que estos test en MAC OS darían igualmente a Safari la última posición.

    Por último decir que la ventaja de que Opera o Chrome usen OpenGL de backend, es que en teoría debería de ser totalmente compatible con cualquier OS compatible con OpenGL (Linux, Windows XP, MAC OS), mientras que el camino tomado ahora mismo por Firefox e Internet Explorer requieren de DirectX 9+ (recomendando DirectX 10) y Windows Vista/7.

    El futuro parece más o menos evidente. Firefox no solo tiene creado el backend de Direct2D/DirectDraw, sino que posee también un Backend OpenGL para Linux/MAC OS e incluso Windows si se fuerza. Así mismo con el tiempo Mozilla abandonará Direc2D/DirecDraw e implementará un Backend en Windows basado en Direc3D, con lo que se obtendrá no solo un rendimiento superior, sino que será más compatible dentro de los diferentes adaptadores de vídeo y versiones de Windows.

 

  • WebGL

    Opera se sumó hace tiempo al carro de WebGL aunque aun no habilitado por defecto.

    Aunque en el apartado anterior se ha hablado de forma extensa sobre la aceleración de hardware y de contenido gráfico, hay que saber diferenciar totalmente WebGL de ello. En el apartado anterior se mostraba la capacidad de los navegadores para acelerar gran parte del contenido en muchas aplicaciones Web y juegos a través de diferentes APIs, como por ejemplo una imagen girando velozmente sobre ella misma, transiciones rápidas… aplicaciones o juegos que podemos encontrar cada vez más en cualquier lado. No hablamos de apartado gráfico anteriormente porque manejásemos gráficos complejos, sino para especificar que son test que hacen uso extensivo del adaptador de vídeo.

    Pero WebGL es totalmente diferente, con WebGL sí asumimos que vamos a trabajar (o al menos que podemos trabajar) con gráficos complejos. WebGL se crea como iniciativa de poder renderizar en Canvas contenido 2D/3D complejo a través de OpenGL. De prosperar y ser realmente eficiente (que es discutible dado la gran sobrecarga de JavaScript) podríamos encontrar a medio plazo juegos con bastante potencial gráfico ejecutado directamente en nuestro navegador. Como lado negativo se encuentra en que WebGL se basa evidentemente en JavaScript, y la sobrecarga de este lenguajes es muy alta. No podremos por tanto comparar jamás una aplicación/juego programada en C++ y OpenGL que programada en JavaScript y WebGL. Esta tecnología jamás será un sustituto ojo, WebGL no llega para desbancar nada, sino para añadir algo que antes era imposible.

    Gracias a WebGL vimos el increíble trabajo por parte de Google y Zigote con «Body Browser», que es una aplicación totalmente práctica, útil y funcional. Realizar algo así sin WebGL sería imposible a día de hoy, se debería de instalar algún complemento en el navegador. Aun así, se ha demostrado que WebGL aun está muy lejos de alcanzar el rendimiento que se obtiene con una aplicación nativa en OpenGL.

    Soy defensor de OpenGL, sobre todo por su facilidad a la hora de programar con él, pero la API DirectX es sencillamente mejor y más rápida. Incluso con ANGLE (implementación de OpenGL sobre DirectX) que tiene que hacer de «traductor», el rendimiento a través de este es superior. En Firefox existe la posibilidad no obstante de usar el soporte nativo OpenGL, pero cuando se opta por este modo, el rendimiento es algo inferior.

    Aun así, no se usa ANGLE por su rendimiento, ya que al final cuando se optimizase WebGL y el soporte nativo es de esperar que el rendimiento de este fuese superior. Se usa ANGLE porque el soporte para OpenGL varía mucho entre diferentes fabricantes. Así por ejemplo, nVidia ofrece el mejor soporte para OpenGL disponible, siendo compatible desde su serie GX 400 con OpenGL 4.3.0. Pero este escenario es totalmente desastroso cuando miramos adaptadores de vídeo Intel, que poseen un soporte para OpenGL mucho más pobre. ANGLE es una solución muy eficaz ya que asegura que sea cual sea el fabricante o el adaptador de vídeo que se tenga instalado, mientras que este sea compatible con DirectX 9.0c podrá ejecutar a la perfección contenido WebGL, y en muchos casos como vemos con un rendimiento superior. Por suerte, Intel está empezando a aplicarse el cuento y entregando controladores decentes para OpenGL en la actualidad, ahora mismo creo que ya soporta en Windows 8 hasta OpenGL 3.0. Recordar que estamos hablando en todo momento de Windows, en Linux o MAC OS no es posible bajo ningún pretexto el uso de la API DirectX, y OpenGL forma parte intrínseca de él. En el caso de Linux es posible usar OpenGL 4.3.0 (la especificación más alta actualmente) siempre y cuando el adaptador de vídeo lo permita, en el caso de MAC OS, este tan solo soporta OpenGL 3.0 y con muchas carencias.

    El test que más nos llama la atención es inmediatamente el tanque de 50.000 peces. Recordemos que realizamos el mismo test bajo HTML5 con 3000 peces, obteniendo Opera en el mejor de los casos cerca de 50 fps. En este caso tenemos el mismo tanque pero usando WebGL, y vemos que es necesario elevar a 50.000 peces para que Firefox no alcance los 60fps. Cualquiera podría decir que si disponemos de WebGL que sentido tiene el test anterior en el que el navegador no podía con 3000. Y volvemos a lo mismo, las peras se parecen a las manzanas en que las dos son frutas, pero nada más. Es más que evidente que si cualquier test html5 se puede pasar a WebGL (con lo que debe de tener un fuerte componente gráfico evidentemente) su rendimiento será infinitamente superior.

 

  • Estándares

    Actualmente parece que existen dos grandes frentes abiertos a la prensa. Si uno es el rendimiento en los test sintéticos, el otro es el proclamar que su navegador es compatible con HTML5, o mejor dicho, pelearse por cual es más compatible en este campo. HTML5 es muy importante en el futuro, pero de nuevo no es el único estándar emergente estos días. Es más, actualmente es infinitamente más usado CSS 3.0 como estándar emergente que HTML5. Tan importante es lo uno como lo otro.

    De nuevo y como era de esperar, todos los navegadores han mejorado su compatibilidad con los estándares existentes, sobre todo en HTML5 como podemos ver en el test de Niels (no podemos compararlo con la comparativa anterior dado que el test de Niels está en constante cambio). Aun así, y pese que Microsoft asegura que en sus test Internet Explorer 10 es el más compatible de cara a HTML5, es Chrome quien posee cierto liderazgo aquí. El problema de Chrome es que aunque es cierto que es más compatible a efectos generales en HTML5 que el resto de los navegadores, no a efectos concretos. Es decir, Chrome implementa la mayoría de funciones de HTML, pero de una forma básica, y lo mismo le pasa con CSS y otras tecnologías. Opera en contrapartida se centra en menos variedad pero de una forma mucho más profunda, intentando cumplir a rajatabla todas las especificaciones de cada sección. Esto hace que en test generalistas como el de Niels Chrome obtenga muy buenos resultados y en otros más específicos como la suite de IE obtenga resultados algo inferiores.

    Sobre la Suite de Microsoft poco podemos añadir, evidentemente es una suite totalmente engañosa para mostrar que Internet Explorer es el navegador más compatible, y en cambio en el test de niels el resultado es deprimente. No obstante Microsoft sigue avanzando a pasos agigantados en cuanto a compatibilidad se refiere, su eterna lacra desde luego… aun a día de hoy muchos webmaster necesitamos crear código redundante y hacer «trampas» para que las web se visualicen correctamente en Internet Explorer, precisamente por no ceñirse a los estándares.

    Sobre WebGL, tanto Firefox como Chrome continúan aumentando su compatibilidad. Opera se ha subido al carro y no ha empezado con mal pie desde luego, aunque en las últimas versiones no es demasiado estable.

    Microsoft optó al final por desgracia de no implementar por ahora WebGL, parece más o menos claro que antes o después lo implementará. Microsoft ya dijo hace tiempo que su postura era dudosa dado a los posibles problemas de seguridad que podrían derivar de WebGL, en cambio como ya explicamos esto es relativo y existen sistemas para evitar estos problemas de seguridad.

 

  • Compilaciones x64

    Internet Explorer 10 ejecuta su interfaz siempre en 64 bits, siendo su chrome en 32bits o 64 bits dependiendo de si se ha habilitado el modo de seguridad avanzada, pero aun cuando habilitamos el modo nativo 64bits vemos que por fin MS se decidió a añadir sus mejoras de rendimiento a la versión de 64bits.

    Firefox continúa ofreciendo versiones diarias de 64 bits con un rendimiento muy similar a las versionese de 32 bits, manteniendo la estabilidad. Por desgracia recientemente se ha anunciado que durante un tiempo deshabilitarán las versiones de 64 bits problemas a la hora de detectar los fallos de su navegador, pero han asegurado que estarán disponibles para el año próximo.

    Opera continúa con sus versiones de 64 bits, y son bastante decentes.

    Sobre Chrome y Safari por otro lado no hay indicio alguno de que una versión de 64 bits pueda ver la luz a corto plazo… habrá que esperar. Es de suponer que eventualmente Chrome sacará una, pero…

 

  • Consumo energético

    ¿Como puede influir un navegador en el consumo energético de un dispositivo? Pues es fácil, dependiendo en gran medida de los recursos que tenga que hacer uso de él. Para ello tan solo tenemos q observar la carga en la CPU/GPU del sistema para hacernos una idea.

    Cuanto menor sea la carga en ambos menor es el consumo, es evidente, pero no está tan claro cuando tenemos que pensar si es la GPU o la CPU quien prima sobre el consumo. Es decir, es mejor tener un consumo de un 10% CPU y 2% GPU o un 2 CPU y 7% GPU. Sería muy complicado llegar a una decisión unánime sin acudir a un tester de potencia y medirlo directamente, pero si más o menos imaginarlo.

    Mirando las gráficas, parece claro que el navegador más eficiente energéticamente hablando dependería del contenido. En un escenario normal, el mejor resultado sería para Internet Explorer o Firefox, en cambio cuando se entrase en test más complejos el ganador sería Safari (por la sencilla razón de que no usaría la GPU y que no sería capaz de ejecutar correctamente el test). Opera en cambio obtendría el peor consumo de forma general por un exceso en el uso de la GPU, y Chrome tampoco quedaría en muy buen lugar, con cargas de CPU/GPU considerables.

    Quizás en un equipo de sobremesa el consumo energético es lo de menos, pero como siempre pensemos en portátiles.

Google I/O 2012 – En Directo

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.