Performances GDI sur un périphérique Windows mobile ou CE

Question

J'ai une application Windows CE qui utilise beaucoup de graphiques vectoriels et qui est parfois très lente. J'utilise actuellement GDI pour le rendu via une image bitmap pour des actualisations sans scintillement. En règle générale, je me glisse sur une partie d'une grande carte 3D. Sur certains périphériques (par exemple, 166mhz SH4), cela devient lent avec des temps d'actualisation de 3 à 5 secondes pour les grands ensembles de données. Ma question est la suivante:

• Quelqu'un a-t-il déjà comparé la vitesse relative des opérations graphiques sous Windows mobile par rapport à Win32? En d'autres termes, les résultats de profilage d'une version Win32 du logiciel sont-ils applicables à une version WinCE, en supposant que nous examinons uniquement les appels GDI.

• Quelqu'un a-t-il déjà essayé d'établir un profil sur une plate-forme WinCE (application C ++), si oui, avec quels outils?

• Est-ce que quelqu'un connait des méthodes pour améliorer la vitesse de dessin sous Windows CE? Je suis en train de regarder FastGraph suite aux réactions d'une question précédente , mais c'est une solution légèrement à plus long terme. Mauvais et tout comme il est, je cherche quelque chose de plus rapide à mettre en œuvre pour une version à venir.

Answer 1

Avant Windows CE 6.0 - et donc toutes les versions de Windows Mobile / Windows Embedded Handheld - le code graphique était implémenté dans un autre processus (GWES.EXE), nécessitant un appel entre processus à chaque fois que vous passiez un appel GDI. Les appels interprocessus CE 5.x coûtent beaucoup moins cher que sur le bureau, mais restent plus onéreux qu’un appel de fonction simple ou un appel en mode noyau.

Sur le bureau, GDI est implémenté en mode noyau depuis NT 4.0. Dans la version initiale de NT 3.1, c'était comme le modèle CE, les appels inter-processus. Pour atténuer la surcharge des appels inter-processus ou des commutateurs en mode utilisateur / noyau, GDI de bureau regroupe les opérations côté mode utilisateur jusqu'à ce que vous fassiez quelque chose qui nécessite de vider la file d'attente - par exemple, sélectionner un stylo ou un pinceau différent, ou en utiliser un. des fonctions héritées qui renvoie autre chose que BOOL - le tampon est plein ou vous le rincez explicitement en appelant GdiFlush .

Windows CE ne dispose pas de cette fonctionnalité de traitement par lots: tous les appels aboutissent à un appel direct au processus GWES, ce qui le ralentit beaucoup. Vous pouvez l'atténuer en effectuant le plus de travail possible lors de chaque appel. Si vous avez besoin d'une ligne complexe, considérez Polyligne plutôt que des appels individuels MoveToEx / LineTo. Essayez de ne toucher que chaque pixel, plutôt que de rendre les objets qui se chevauchent, et utilisez la région non valide pour peindre uniquement les parties de l’écran nécessitant d'être repeintes (utilisez GetUpdateRgn ou GetUpdateRect , mais faites-le avant d'appeler BeginPaint , ce qui marque la région valide).

Le modèle d’accélération graphique CE est assez basique, basé sur des bit-blits. Il ne prend pas en charge l'ensemble plus large des fonctionnalités prises en charge par les pilotes de périphériques de bureau Windows 2000. Que l'accélération soit disponible ou non dépend du point de savoir si le matériel dispose d'une puce d'accélérateur. De nombreux périphériques utilisent le contrôleur LCD intégré au processeur de l'application, ce qui ne produit généralement pas d'accélération.

Vous pouvez simuler le comportement de CE sur le bureau en désactivant le traitement par lots, en utilisant GdiSetBatchLimit pour définir la limite sur 1. Pensez également à utiliser le pilote graphique SVGA pour désactiver l'accélération. Sous Windows Vista ou Windows 7, GDI n’est pas accéléré si vous utilisez l’environnement Aero, toutes les opérations sont implémentées dans le logiciel, bien que Windows 7 ait rajouté de nouvelles fonctionnalités d’accélération matérielle «bit blit».

Windows CE 6.0 a un nouveau modèle de processus et de noyau, qui met GDI en mode noyau comme sur le bureau Windows (avant Vista), de sorte que le coût d’appel d’une fonction GDI devrait être légèrement réduit. Il n'y a toujours pas de traitement par lot.

Answer 2

Je n'ai pas beaucoup de connaissances graphiques, mais par expérience, si vous voulez être rapide avec certaines choses liées au matériel spécifique, plus vous vous rapprochez du "métal". plus vite vous pouvez obtenir (et plus cela devient difficile!). Vous pourriez donc envisager d’utiliser le tirage direct ou Direct 3D (bien que je pense qu'ils abandonnent D3D et passent à OpenGL ES pour WM7) . Vous voudrez peut-être examiner la manière dont les développeurs de jeux utilisent.

Sur la question des profils, je n’en ai trouvé aucun, mais je construis mon propre .

Answer 3

J'ai fait beaucoup de ce type d'analyse comparative, et les opérations GDI sont plus lentes sous WinCE que sous Win32 normal, mais seulement plus lentement par rapport aux processeurs plus lents des périphériques WinCE. En d’autres termes, l’utilisation de GDI dans WinCE ne semble pas avoir eu d’effets négatifs sur les performances.

Désolé, je n'ai pas de réponses à vos deux dernières questions.