L'utilisation des fenêtres superposées pour créer des bordures de fenêtres lisses

Question

Nous développons une application à la peau avec divers bords arrondis sur la plupart de ses fenêtres. J'utilise des régions de fenêtre pour définir des formes non-rectangulaires, mais presque tout le monde des objets à l'aliasing en dents de scie ce qui provoque, parce que les pixels ne peuvent être soit totalement opaque ou totalement transparent.

Je suis venu avec une solution à cela en utilisant les fenêtres en couches, mais nous voulons nous assurer que cela sur une variété de systèmes fonctionnera (et je l'espère bien fonctionner), et je veux voir si quelqu'un a une meilleure idée, ou les moyens d'optimiser ce que je fais. Je sais que les fenêtres en couches EXIGE Win2000 ou plus tard, et qui est très bien, comme cela est déjà une exigence pour d'autres raisons. A partir de quelques tests de base, il semble correct sur Vista, mais encore n'y a aucune garantie.

Voici ce que je fais: j'ai une fenêtre, appelez A, avec des commandes et du texte et tout comprend cette fenêtre. J'ai fenêtre B comme un enfant de la fenêtre A, sauf qu'il a le style WS_POPUP au lieu de WS_CHILD, il peut donc se positionner en dehors de la région A et est dessiné au-dessus des commandes de A. Fenêtre B a aussi le style WS_EX_LAYERED, et l'initialisation, je l'appelle UpdateLayeredWindow avec le drapeau ULW_ALPHA et une source de courant continu avec un bitmap de 32 bits avec un canal alpha, pour qu'il puisse dessiner avec alpha par pixel.

Le bitmap utilisé dans la source de courant continu pour la fenêtre B est à peu près juste les pixels autour de la frontière de la fenêtre que je veux fondre en douceur de l'arrière-plan de la fenêtre en pleine transparence. Je sauter toute approche en deux fenêtres et il suffit d'utiliser une seule fenêtre en couches, sauf que lorsque vous utilisez UpdateLayeredWindow, il est tiré d'un tampon conservé en mémoire, au lieu des messages WM_PAINT typiques et tout cela, et essayer d'obtenir contrôles enfants interactifs (et les fenêtres de l'enfant) pour travailler bien avec ça sonne comme un tracas remarquable (et serait probablement même pas pour tout).

Alors, il est essentiellement fenêtre A avec tous les contrôles de l'enfant et que ce soit, avec fenêtre B flottant directement sur le dessus de celui-ci, tirant une belle bordure lisse. Je répondre à WM_MOVE messages et ainsi de suite par fenêtre mobile B avec elle, et j'ai fenêtre B désactivé il ne peut jamais se concentrer ou d'entrée (clics déjà aller à travers, car certaines parties qui sont de zéro opacité, comme la majorité de ses parties intérieures, déjà sont exclus de la sélection).

Pour kicks, voici ce que les pièces ressemblent, pour montrer ce que je veux dire un peu mieux.

• arrière-plan de la fenêtre A , avec cyan utilisé pour masquer les pixels entièrement transparents.
• bitmap de fenêtre B , avec un canal alpha (non illustré, bien sûr, il est un jpg) qui mélange les pixels non noirs en transparence.
• résultat combiné

Alors, cela fonctionne, mais je ne peux pas être certain qu'il est vraiment la meilleure façon de le faire. J'ai deux questions:

• Est-ce son acceptable, ou est-il quelque chose de terrible aveuglante?
• Comme il travaille actuellement, il semble que c'est l'utilisation d'un hors écran tamponner la taille de la fenêtre (qui peut être jusqu'à 1024x768), même si très peu de pixels de celui-ci ont toutes les données d'opacité non nulle - serait-il vaut les frais généraux et la complexité supplémentaire de le découper en morceaux de frontière séparés et les compositing ensemble?

Answer 1

Mon produit utilise des fenêtres en couches pour dessiner les petits onglets que j'attache à chaque fenêtre. J'ai utilisé les fenêtres en couches pour obtenir l'arrondi lisse sans aliasing. Le seul problème méchant que j'ai rencontré à ce jour est que certaines fenêtres OpenGL griffonner sur le dessus des fenêtres superposées sur Windows XP et Vista sans DWM. Son problème de bas niveau et Microsoft n'a pas été terriblement utile. Vous pouvez le reproduire en ouvrant Google Earth et en faisant glisser votre application sur la fenêtre principale de rendu, la fenêtre disparaîtra en couches.

Answer 2

Je l'ai trouvé une chose: avoir des pièces de cadre séparées peut rendre beaucoup plus rapide que d'avoir une seule fenêtre de cadre géant, avec une grande étendue de pixels vides au milieu. Je n'ai pas de chiffres réels, mais juste d'un test rapide d'essayer les deux, il y avait un temps de latence perceptible lorsque plusieurs fenêtres avec des fenêtres plein cadre se chevauchaient, mais quand leurs cadres ont été découpés en composants plus petits, il était beaucoup plus souplement . Quels que soient les frais généraux d'avoir plusieurs fenêtres superposées avec leurs propres contextes de l'appareil ne contribue pas beaucoup, et ayant de grandes étendues de pixels (en blanc ou non!) Contribue encore beaucoup plus de charge.

Answer 3

1. Ne pas oublier de tester sous RDP et VM (Hyper-V et VMWare)
2. Essayez plusieurs cartes GFX et sur les netbooks et les ordinateurs portables (le cas échéant).