Chronométrer une méthode et des threads en .NET

Question

J'ai deux threads dans mon application - le thread UI principal et un autre thread initié par le gestionnaire d'événements wm_WiiMoteChanged (un thread en arrière-plan). Dans le thread principal, je fais un traitement vidéo. J'ai une fonction appelée processFrame montrée ci-dessous. J'utilise ce code pour mesurer le temps de traitement de chaque image et donc le taux d'images par seconde.

Si je commente la ligne wm.WiiMoteChanged ... (voir ci-dessous), les taux d'images sont d'environ 15-20 fps et en regardant la vidéo, cela semble correct (il y a un petit décalage).

Mais quand je décommente la ligne, c'est-à-dire j'ajoute le gestionnaire d'événements (qui générera son propre thread), les ips passent à 40-50, mais c'est définitivement faux - la vidéo est en fait plus saccadée.

Quelqu'un peut-il m'expliquer pourquoi cela se produit? Merci.

private void Main_Load(object sender, EventArgs e)
{
    try
    {
        wm.Connect();
        //wm.WiimoteChanged += wm_WiimoteChanged; 

        wm.SetReportType(InputReport.IRAccel, true);
        wm.SetLEDs(false, false, false, true);
    }
    catch (Exception x)
    {
        MessageBox.Show("Erreur: " + x.Message);
        this.Close();
    }
}

Plus de code:

private void processFrame(object sender, EventArgs e)
{
    DateTime curr = DateTime.Now;
    performOperation();
    TimeSpan currTime = DateTime.Now - curr;
    lblFPS.Text = (1000 / currTime.Milliseconds).ToString() + " ips";
}

MODIFICATION

Une découverte intéressante, cela se produit uniquement lorsque cette ligne est présente dans wm_WiimoteChanged.

ibxOutput.Image = new Image(_irViewAreaBitmap);

Note latérale : cette ligne est aussi la cause du décalage plus élevé - le traitement effectué avant le réglage de cela est en fait rapide!

Answer 1

Parce qu'en ajoutant un gestionnaire d'événements, vous répondez à ces événements WiimoteChanged et exécutez du code supplémentaire.

Le gestionnaire contient-il un verrouillage? Je vous suggère de publier le code pour wm_WiimoteChanged()

MISE À JOUR: Je vous suggère d'utiliser System.Diagnostics.Stopwatch plutôt que DateTime.Now. Il est probable que DateTime.Now ne soit pas assez précis.

Answer 2

D'accord, je suis un peu lent ici, mais je ne comprends pas le calcul des images par seconde?

Ne devrait pas votre IPS être en fait le nombre de fois que ProcessFrame est appelé en une seconde? Si vous mesurez cela, vous pourriez obtenir un résultat plus précis.

Aussi, pour mesurer le temps, vous feriez mieux d'utiliser StopWatch; il est fait à cet effet.

Answer 3

Est-ce qu'un seul cadre est rendu à l'écran pour chaque invocation de la méthode processFrame ? Je soupçonne que le rendu se fait ailleurs et est bloqué par le code dans le gestionnaire WiimoteChanged, donnant ainsi à votre méthode processFrame plus de temps processeur.

Pour que votre mesure de FPS soit exacte, vous devez vous assurer que processFrame est appelé exactement une fois par cadre. Vous devriez probablement mesurer le temps entre les invocations successives également plutôt que de mesurer la durée de performOperation, à moins que processFrame soit appelé immédiatement à nouveau à son retour.