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! =)