Hoje me deparei com um comportamento estranho num projeto Windows nativo: no começo não tinha percebido, mas o aplicativo estava processando o movimento do mouse constantemente (cerca de 1,5 vezes por segundo). Na Win32 API, isso significa que o loop do aplicativo estava obtendo (do sistema) e despachando a mensagem WM_MOUSEMOVE, que passaria pela WindowProc do aplicativo. O pior é que o mouse estava parado e as coordenadas do mouse sempre vinham iguais.

Verifiquei se o mouse estava com problema e também desconectei dispositivos USB da máquina. Nada. Verifiquei se poderia ser bug introduzido no código depois de algumas alterações recentes e certifiquei que o loop do aplicativo estava correto. Aparentemente, o código estava OK.

Resolvi ver quais aplicativos e serviços estavam rodando no sistema e fui encerrando um por um. Estava ouvindo música no Windows Media Player e, assim que fechei o Media Player, meu aplicativo parou de processar o WM_MOUSEMOVE. Hum, quem diria.

Já percebeu que quando o Windows Media Player está tocando algum arquivo de mídia, o screensaver nunca é executado? Porém, quando o Media Player está aberto mas não está tocando nada, o screensaver chega a ser executado. Aí está a explicação tanto do comportamento do Windows Media Player vs Screensaver como do “bug” do meu aplicativo: o Media Player fica gerando a mensagem WM_MOUSEMOVE a todo momento (simulando que o mouse se movimentou), enquanto algum arquivo de mídia estiver sendo executado.

Fica a dica caso o seu aplicativo/jogo realize muito processamento em resposta ao movimento do mouse ou tenha alguma operação que dependa do movimento do mouse. Dependendo do quão crítico esse tipo de interferência seja para o seu projeto, é melhor responder ao movimento do mouse somente quando o mesmo se deslocar acima de um threshold.

Esse comportamento também é interessante para evitar que o screensaver seja ativado no meio de uma partida do seu jogo, por exemplo. Entretanto, não recomendo essa abordagem, principalmente para mobile, pois isso consumirá mais bateria do aparelho (acho melhor lidar com as interrupções do aparelho e com o ciclo de vida do aplicativo).

PS: antes que alguém me diga para usar outro aplicativo como Winamp ou VLC, vale lembrar que os seus usuários podem estar usando o Windows Media Player junto com seu aplicativo/jogo ou mesmo ter outros aplicativos que interferem de maneira similar ao comentado aqui.

Be Sociable, Share!

• 

Talvez por costume com linguagem C e trabalhar com legacy code (alocando com malloc), já vi (e também fiz) isso em alguns projetos:

#include <iostream>

int main(int argc, char *argv[])
{
  const int MB = 1048576;

  char *mem = new char[2047 * MB];

  if (mem)
  {
    std::cout << "Almost 2GB of memory successfully allocated!" << std::endl;
    delete[] mem;
  }
  else
  {
    std::cout << "Bad allocation!" << std::endl;
  }
}

Verificar se a variável mem é válida após alocar memória é algo correto a se fazer, não? Quase. No código C++ acima, o else nunca será executado: quando os quase 2GB alocados acima são realmente alocados, o if é executado. Mas quando não é possível alocar a memória, o que ocorre é uma exceção (std::bad_alloc) e o else não é executado.

Poderia reescrever com um try-catch:

#include <iostream>

int main(int argc, char *argv[])
{
  const int MB = 1048576;

  try
  {
    char *mem = new char[2047 * MB];

    if (mem)
    {
      std::cout << "Almost 2GB of memory successfully allocated!" << std::endl;
      delete[] mem;
    }
  }
  catch(const std::bad_alloc &exception)
  {
    std::cerr << "Exception: " << exception.what() << std::endl;
    return 666;
  }
}

Ou então poderia alocar usando new(std::nothrow), que retorna um ponteiro null quando não é possível alocar memória:

#include <iostream>

int main(int argc, char *argv[])
{
  const int MB = 1048576;

  char *mem = new(std::nothrow) char[2047 * MB];
  
  if (mem)
  {
    std::cout << "Almost 2GB of memory successfully allocated!" << std::endl;
    delete[] mem;
  }
  else
  {
    std::cout << "Bad allocation!" << std::endl;
    return 666;
  }
}

Be Sociable, Share!

•