Com a ajuda do Ademar escolhemos um bom caso de uso. Um “bouncing game”.

O Jogo

As flags

As flags que comentarei neste post são:

• QGraphicsScene::ItemIndexMethod
• QGraphicsView::OptimizationFlags
• QGraphicsView::ViewportUpdateMode

Os resultados

* Os testes foram executados em um Nokia 5800, RM-356 rodando firmware V51.0.006 com Qt 4.6.3.
** O eixo Y dos testes é o FPS. Quanto maior, melhor.

Testes com 10 elementos

Primeiro de tudo, tentei as 4 formas de update da Viewport usando 10 elementos na tela. O MinimalViewportUpdate e o SmartViewportUpdate renderam a maior taxa de FPS (34 e 33.5). A documentação da biblioteca mostra que NoIndex é a melhor opção para cenas dinâmicas. Bem, a diferença é bem pequena, mas é verdade.

Neste caso, para os próximos testes, usarei sempre NoIndex.

E quanto às flags?

Dado os melhores resultado dos últimos testes (SmartViewportUpdate and BoundingRectViewportUpdate) foi feito outro teste com as duas flags de optimização QGraphicsView::DontSavePainterState e QGraphicsView::DontAdjustForAntialiasing. A conclusão foi que estas flags de optimização rendem uma pequena melhora no desempenho, mas somente se você puder controlar precisamente a maneira como seus elementos são desenhados. Caso contrário você pode enfrentar problemas de renderização.

20 elementos

30 elementos

40 elementos

Lições aprendidas

É importante selecionar corretamente a maneira como serão feitos dos updates da Viewport. Isso pode fazer a diferença.

Se existem muitos elementos dinâmicos, e se eles estão espalhados por toda a tela, é mais barato pintar toda a tela (ou pelo menos o bounding rect) do que tentar determinar a área afetada pelo movimento e só pintar estes espaços.

Para ser honesto eu estava esperando um resultado melhor do FullViewportUpdate, mas acredito que obteríamos melhores resultados (do que o BoundingRect) se fosse utilizado um background não estático.

Mas… E se..?

Q:O que aconteceria se fosse utilizado somente um único graphicsItem para pintar todas a bolinhas? O que aconteceria se uma bolinha não fosse um ítem, mas apenas um objeto com um método de renderização?

R: Fiquei um pouco surpreso com o resultado, mas o desempenho do Qt (especialmente os states do QPainter) melhorou muito desde a versão 4.6 e o resultado deste teste obteve resultados piores do que usando vários QGraphicsItems. Esta abordagem obtém melhor rendimento que a abordagem padrão apenas se o número de elementos é maior que 60.

Depois de escrever os testes, o que acontece com o código?

Usando os conhecimentos adquirido pelos testes e com a ajuda de uma das designers do INdT – Nara – estou liberando uma versão de um jogo baseado na engine dos testes. Não está totalmente concluído, faltam alguns elementos, mas já está jogável. =)

Symbian package here!

Por enquanto segue apenas o demo, e em breve a versão completa na Ovi Store mais perto de você!

O fato de sermos usuários Linux não nos afasta mais deste objetivo. O colega Lizardo, não muito feliz com a dependência do Janelas, adaptou com sucesso o famigerado GNUPOC para funcionar com o Qt 4.6.X, dando-nos assim um ambiente agradável de desenvolvimento Qt/Symbian no Linux.

Graças a ele temos qmake, QGraphicsView e QCoisas funcionando da mesma forma como funcionavam no desktop.

E as APIs específicas como GPS, sensores e rede?

A idéia do Qt everywhere inclui abstrair a API não tão bonita do symbian e maemo (e outros) para uma única API Qt.

Seguindo este princípio lançaram, dia 15/02, um pacote beta do Qt-Mobility Project, com classes Qt para sensores, GPS, contatos e etc.

A instalação é simples mas, para quem seguiu os passos do Lizardo, basta utilizar este script e passar o diretório onde o download do pacote foi feito:

qt-mobility-install.sh <directory>

*Observação: Não esqueça de setar as variáveis de ambiente $EPOCROOT e $PATH, de forma que o qmake utilizado seja o da instalação para S60

I have! =)

Neste meu estudo produzi uma espécie de Data Provider, que é um serviço que fica rodando sobre o DBus e é responsável por receber atualizações de rss de um determinado blog. Os clientes não acessam diretamente o rss mas sim este provider, via canal DBus, e são notificados quando ocorre alguma atualização.

O conceito é simples, o código também. Não estou usando nada como QDBusAdaptors ou classes afins. Na verdade, o exemplo é válido pela didática pois exemplifica uma forma de enviar objetos “estranhos” via DBus.

O código pode ser obtido com:
git clone http://labs.danilocesar.com/git/qdbus-test.git

Ao menos uma das previsões de 2008 saiu =)

[UPDATE 14/01 09:40]

</joke>

Navegando pelo techbase encontrei uma solução:

nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

Fica aí a dica!

[]‘s

Vou-me embora para Pasárgada
Lá sou amigo do Reis

Novidades:

1 – Estou formado em Ciência da Computação pela UFPR.

2 – Estou deixando Curitiba. Após 22 anos na saudosa Curitiba estou deixando-a, e indo para Recife-PE.

Só tenho o que agradecer a esta magnífica cidade, à minha família que fica por aqui, e aos meus colegas da Mandriva, com os quais pude aprender bastante.

E esperar que este novo desafio seja tão bom e gratificante quanto o antigo.

Projeto da matéria de Processamento de Imagens, o objetivo era fazer um tracker de pessoas em um determinado vídeo.

Na especificação havia:

• O vídeo será uma sequência de imagens PPM nomeada da forma <nome>_<seq>.ppm. Ou seja, se a sequência se chamar tracker, o primeiro arquivo será o tracker_00.ppm.
• O vídeo será testado em dois casos: No primeiro haverá uma pessoa, no segundo duas.
• As pessoas devem ser marcadas com cores diferentes, e a mesma cor para cada uma das pessoas.
• Em nenhum momento as pessoas se cruzam.

Assim fica fácil! =)

Segue algumas screen shots:

Como de costume, o código está no SVN em:

http://danilocesar.com/svn/pitracker/

E as imagens podem ser encontradas no site da matéria.