Uma das discussões dentro do assunto é a já anunciada mudança de nomes: Sempre houve uma grande “crise de identidade” quanto a como os desenvolvedores se chamavam: Por um lado, programadores não queriam seu nome relacionado a IDE do Flash, que pode trazer uma idéia de amadorismo (de quando se programava na timeline) e remeter a tempos do “skip intro”, e por outro lado não queriam ser chamados de Flex developers, já que não faziam arquivos MXML.

A Adobe percebendo essa confusão decidiu colocar ordem na casa e separou ferramenta, framework e plataforma: Assim, uma pessoa pode sem confusões falar que programa no Flash Builder(ferramenta), usando o Flex SDK em as-only(framework) e exportando arquivos .swf pra Flash Platform, ou que programa no FlashDevelop, compilando com o Flash Professional, exportando para o AIR (correspondente do Flash Platform para desktop).

Eu fiquei satisfeito com a mudança (a não ser talvez pelo nome Flex SDK, que não mudou por falta de necessidade), mas vejamos como o mercado reage a essa mudança.

Há algumas semanas estava procurando um meio rápido de fazer detecção facial no flash, pra tentar fazer uma espécie de realidade virtual, como a do Johnny Lee e seu wiimote:

Minha primeira idéia foi tentar portar alguma em C com o Alchemy… sem sucesso, já que o Alchemy não compila arquivos .dll e não encontrei nenhum programa opensource pequeno (OpenCV é muito grande e eu tenho muito pouco conhecimento em C).

Bem, com uma certa ajuda do Google, encontrei esse post, com uma solução que processa os Bitmaps no servidor e devolve ao Flash via socket. Legal, mas não achei a solução muito elegante, então deixei pra lá.

Mas hoje me mandaram esse link no twitter, uma coisa levou a outra e encontrei esse post, falando exatamente sobre o que estava procurando:

Realtime Face Detection in Flash from squidder on Vimeo.

Em cerca de uma hora, montei um exemplo simples, mas já meio promissor, pra ver como ficaria a performance no flash e o feeling da VR. Clique aqui para ver, e aqui para pegar o source.

Vi no http://www.bytearray.org/?p=423

Antigamente, o player não tinha o costume de consumir muita RAM, o problema recaía no uso pesado do processador (que melhorou com o Player 10, que começa a usar recursos da placa de vídeo) mas temos uma série de novos recursos (ByteArray, BitmapData…) que podem consumir muitos megas da memória. Além disso, desde o ActionScript 2 o Garbage Collector (GC) do flash tem dificuldades em manter a RAM limpa, pelo próprio modo como as referências internas são feitas, como explicado pelo Jim Corbett neste vídeo em (25:30):

Mas afinal, o que é o Garbage Collector e como ele funciona?

O GC é o processo que limpa a sujeira que você deixou pra trás: ele retira da memória objetos que não serão mais usados pela aplicação. E como ele fica sabendo disso? Bem, atualmente isso é feito no flash de duas maneiras distintas: Reference Counting e Mark Sweep.

O mais simples dos métodos, o Reference Counting era usado desde o Actionscript 1.0, e a idéia é bem prática: toda vez que alguém faz referência a um objeto (ou seja, provavelmente será usado), um contador de uso do objeto é acrescido de 1. Toda vez que uma referência é retirada, esse contador é decrescido de 1. Desse modo, quando não há nada fazendo referência ao objeto (o contador voltou a 0), ele é marcado para ser retirado da memória. Exemplo:

var obj1:Object = {var1:"oi"}; // contador em 1, o objeto está sendo referenciado por obj1
var obj2:Object = obj1; // contador em 2
delete obj1; // contador em 1, não está mais sendo referenciado por obj1
trace( obj2.var1 ); // retorna "oi". Como pode ver, o objeto e referências a ele são coisas distintas
delete obj2; // contador em 0. aqui o objeto é alvo do GC para remoção

Algumas observações:
- Como podem ver, o objeto e a variável que guarda o objeto são coisas distintas. Mesmo se não houver nada fazendo referência a { var1:”oi” }, ele não deixa de existir. Por isso a importância do Garbage Collector.
- Quando ninguém mais “fala sobre” o objeto (referência a variáveis, escutas de evento, enterFrames…), é uma justificativa para ele ser jogado fora. Mas podem haver casos onde o objeto é referenciado, mas não é mais usado.

Pense no seguinte cenário: A guarda B, B guarda C e C guarda A. No final das contas, pode ocorrer o caso de nenhum deles ser mais utilizado, mas todos estão sendo referenciados no código, logo não serão retirados da memória. Para corrigir esse problema, outra técnica é utilizada: o Mark Sweep. Nesse método, o flash percorre a partir do root todos os objetos que consegue encontrar, recursivamente, e os marca. Se algum objeto não for marcado, significa que ele não está sendo utilizado. No caso que falei acima, se nem A nem B nem C tiverem uma ligação direta ou indireta com a raiz da aplicação, eles serão removidos da memória.

Note que limpar a memória é um processo lento, que percorre todos os objetos, logo não é acionado com tanta frequência: aproximadamente uma vez a cada 60 segundos ou quando a alocação de memória der um pulo maior que 20% o uso atual (dados não oficiais). De qualquer modo, não é previsível quando um objeto vai ou não ser removido da memória. Note que, enquanto o objeto existir, isso quer dizer que os loops, acessos a arquivos, sons, etc, continuação ser processados, então fica evidente a importância de se saber como manter a memória limpa.

Em meu próximo post tentarei explicar como podemos ajudar o GC do flash em seu trabalho.

referências:
http://blogs.eyepartner.com/adrian/flex/flex-tip-6-garbage-collection-in-flex/GC Flush em Flex

http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html gskinner falando sobre o GC


stage.quality = "medium";
var noise:BitmapData = new BitmapData( 300, 1000 );
noise.perlinNoise( noise.width, noise.height, 2, Math.random() * 256, true, false, 7, true );
var container:Sprite = new Sprite();
container.x = 100;
container.y = 150;
addChild( container );

var count:uint = 1;
function animate() {
var bmd:BitmapData = new BitmapData(noise.width, 2 );
bmd.copyPixels( noise, new Rectangle( 0, count, noise.width, 2 ), new Point() );
var elm:Sprite = new Sprite();
var line:Sprite = createLine( bmd );
line.x -= line.width / 2;
line.y -= line.height / 2;
elm.addChild( line );
elm.addEventListener( Event.ENTER_FRAME, onLineFrame );
container.addChild( elm );
container.scaleX = container.scaleY = 2;
container.x = 250;
container.y = 350;
count += 5;
if ( count >= noise.height - 1 ) {
count = 1;
}
}
function onLineFrame( e:Event ):void {
var elm:Sprite = e.target as Sprite;
var ratio:Number = elm.scaleY;
ratio -= 0.02;
elm.scaleX = ( ratio / 1.5 ) + 0.5;
elm.scaleY = ratio;
elm.y = -160 * ( 1 - ratio );
elm.alpha = ( ratio * 1.5 ) - 0.5;
if ( ratio <= 0.3 ) {
elm.parent.removeChild( elm );
elm.removeEventListener( Event.ENTER_FRAME, onLineFrame );
}
}
function rgb2hex( r:int, g:int, b:int ):Number
{
return ( r << 16 ) | ( g << 8 ) | b;
}
//animate();
setInterval( animate, 10 );


1. Criei um PerlinNoise estreito e longo, com stitch = true pro final emendar no começo;
2. Criei um método pra criar uma linha de acordo com um BitmapData de y = 1;
3. Criei um método pra criar as linhas uma a uma a aprtir de “fatias” do PerlinNoise;
4. Em cada linha, fiz um método pra montar o “3D”, diminuindo, movendo e aplicando alpha.

O que eu quero colocando isso aqui? Oras, que vocês possam me dizer o que está errado, o que é besteira e como melhorar.

Novas Interações e o Papel do Designer

Alguém que passasse cinco anos dormindo acordaria em outro mundo: celulares sem teclado, videogames com reconhecimento de movimento, celebridades fazendo música movendo peças em uma grande mesa digital… Uma revolução em questão de interação que está se instalando com velocidade assustadora e precisa ser entendida por nós, designers.

Os exemplos acima são já cotidianos: tratam-se do iPhone, da Apple, o Nintendo Wii e o Reactable, usado pela cantora islandesa Björk. E o que esses produtos têm em comum? A primeira conclusão lógica seria dizer que por parte de hardware uma maior liberdade é dada ao usuário: a morte dos botões e mouse e o aparecimento de novos meios de se interagir. Mas essa é só a ponta do iceberg.

Não que tudo isso não seja novidade, mas inovações só são digeridas pelo mercado se o mesmo estiver preparado pra isso: nada de novo costuma ser visto por bons olhos se estiver distante demais da realidade, senão assusta. O que está acontecendo, ao contrário, é algo que a massa consumidora está mais que preparada pra entender.

Atualmente, temos consumidores com um perfil muito adaptável a novidades. Melhor que isso, temos pessoas ávidas pelo novo, pelo diferente, evolução de um modelo de consumo que trouxe à tona os chamados prosumers, os que querem algo exclusivo e que os define como ser. Além disso, temos uma série de tecnologias que servem de base para que o usuário esteja pronto para interagir com essas novas interfaces. A internet, por exemplo, trouxe algumas metáforas do real - como páginas, botões, formulários - como tentativa de criar uma interação fluida por para o usuário, mas está criando uma identidade própria, principalmente quando tenta subverter a linearidade das páginas estáticas. A adaptação que a tecnologia Flash trouxe quando foi introduzida na internet se assemelha ao que está sendo assimilado agora com telas multi-touch e mecanismos sensíveis ao movimento corporal, especialmente em termos de liberdade de interação. Oras, a tela sensível ao toque existe desde 1971, mas está se tornando popular apenas nos últimos anos, isto é um claro sinal de que o momento é propício para explorar essas novidades.

Um ótimo exemplo de novidade é o iPhone, o telefone da Apple. Antes de mais nada, a Apple sempre foi uma empresa aberta a esse tipo de novidade, do mouse ao “click wheel”, espécie de círculo sensível ao toque do Ipod. Pois bem. Ao se ver o iPhone pela primeira vez, parece que falta algo: é uma grande tela e um botão logo abaixo. Pois esta tela é multi-touch, e toda interação se dá pelo toque de seus dedos: para destravar o aparelho, por exemplo, tudo o que se deve fazer é deslizar uma espécie de barra na tela. E todo o resto é extremamente intuitivo: para girar uma imagem dentro do iPhone, você faz o movimento de giro com dois dedos, muito próximo do que faria com uma imagem real em cima de uma mesa. Para ampliar a imagem, também com dois dedos o que se faz é distanciar um do outro, como se estivesse abrindo um espaço na imagem. Muitas possibilidades, mas pouca exploração de algo que seja distante do real.

Outro exemplo citado foi o Wii, console da Nintendo: neste caso, a interação se dá pelo controle, que reconhece seu movimento nas três dimensões. Isto quer dizer que, ao invés de apertar um botão para pular, por exemplo, você faz o próprio movimento para pular. Esse tipo de movimento o usuário fazia sem perceber nos consoles antigos. Em um jogo de corrida, por exemplo, a tendência era mover o controle e o próprio corpo de acordo com o carro. Outro modo de se interagir, e outro reflexo do real.

Já com o Reactable, melhor definido como um sintetizador touchscreen, explora os recursos que a tecnologia oferece, dando ao usuário um novo repertório dentro da mesma tecnologia. Trata-se de uma espécie de mesa sintetizadora onde um ou mais usuários manipulam artefatos(objetos reais) que são interpretados pela mesa de acordo com o tipo de artefato, posição e rotação. Estes, por sua vez, interagem entre si, dependendo de sua função: um gera uma nota com frequência específica, outro pode, por exemplo, alterar a batida(BPM), enquanto um terceiro cria uma distorção senoidal, tudo passível de mudança de acordo com sua distância do centro da mesa e um do outro, face dos objetos, além de várias configurações feitas com as próprias mãos -a mesa se ilumina, criando todo o ambiente, com ondas e botões.

Como pode-se perceber, a tecnologia em si não é algo interessante ao usuário. O importante, como sempre, são os possíveis usos da tecnologia. E é trabalhos de nós, projetistas, criar essas interações, explorar o que há de novo para tornar a experiência inovadora, útil, agradável e intuitiva.