So beschleunigen Sie Ladezeit für MFC-Bändchen-Anwendung

Question

Ich habe eine native MFC C++ - Anwendung, für die ich eine Band UI-basierte Version und eine Toolbar-basierte Version habe. Beide EXEs haben eine ähnliche Größe (~ 30 MB), aber das Ausführen der bandbasierten Version dauert ungefähr 25 Sekunden, während die Toolbar-Version ungefähr 5 Sekunden dauert. Dies dient nur dazu, das Rahmenfenster mit Werkzeugen anzuzeigen. Ich habe den Start der Band UI basierte Version profiliert, und sicher genug, die Zeit, in CMFCRibbonBar::LoadFromResource und tiefer wird in

BOOL CMFCRibbonInfoLoader::LoadImage(CMFCRibbonInfo::XImage& image, BOOL bSingle) 
{ 
' 
' 
' 
    image.m_Image.SetTransparentColor(GetGlobalData()->clrBtnFace); // 15% 
    image.m_Image.SmoothResize(dblScale);       // 64% 
' 
} 

Graben tiefer, viel Zeit damit verbracht, scheint manuell die Symbolleiste Schattierung ausgegeben werden ~ 44% der Gesamtzeit.

Gibt es eine Möglichkeit, diese Ladezeit zu beschleunigen, möglicherweise durch Festlegen eines nicht transparenten Zeichenschemas? 25 Sekunden, um ein Programm zu starten, scheint ein bisschen übermäßig, das ist auf einem 8-Kern 4 GHz AMD 8350 mit dem EXE-Bild von einer SSD kommen.

Edit: Versuchte das folgende, das half, das Problem zu verstehen, aber nicht wirklich für eine nützliche Antwort.

Nach einigem Stöbern scheint ein Aufruf an afxGlobalData.EnableRibbonImageScale(FALSE); die Skalierung zu deaktivieren, kann aber auf einigen Monitoren zu schlechten Ergebnissen führen. Wenn die Bildgrößen für den Monitor richtig sind, 40x40 Pixel auf meinem 1920x1080 Display, wird die Skalierung ebenfalls übersprungen. Ich habe es noch nicht ausprobiert, aber ich würde mir vorstellen, wenn Sie HDPI-Bilder für alle Ribbon-Steuerelemente angeben und Sie das Glück haben, 1: 1-Skalierung für Ihre HDPI-Bilder zu erhalten, würde es auch übersprungen werden. Durchsuchen des MFC-Quellcodes (\ Programme (x86) \ Microsoft Visual Studio 14.0 \ VC \ atlmfc \ include \ afxglobals.h) für und m_dblRibbonImageScale den Großteil des relevanten Codes.

Wenn die großen Tastenbilder nicht 32x32 sind, scheint der Farbbandeditor sie so zu behandeln, wie sie waren, und zerhackt die Basis-BMP falsch. Die Größe eines großen BMP-Basisbuttons auf 40x40 zu ändern, führte zu Müll auf dem Bildschirm.

Edit: Ich hatte gedacht, dass die Antwort von Vlad funktionieren würde, aber anscheinend ist das in einer MFC-Menübandressource verwendete XML nicht Ribbon XML. Siehe verwandte Frage auf MSDN here.

bearbeiten Eine weitere Diskussion auf MSDN here

Answer 1

Die Seite Specifying Ribbon Image Resources heißt es:

Für jedes Bild, die genaue Pixelgröße ist abhängig von der Anzeige Auflösung oder Punkte pro Zoll (dpi) , des verwendeten Monitors. Bei 96 dpi sind große Bilder 32x32 Pixel groß und kleine Bilder sind 16x16 Pixel groß. Die Bildgrößen erhöhen sich linear um zu dpi, wie in der folgenden Tabelle dargestellt.

DPI  Small Image  Large Image 
96 dpi 16x16 pixels 32x32 pixels 
120 dpi 20x20 pixels 40x40 pixels 
144 dpi 24x24 pixels 48x48 pixels 
192 dpi 32x32 pixels 64x64 pixels 

Das Ribbon-Framework skaliert Bildressourcen nach Bedarf. Allerdings , da die Größenänderung kann unerwünschte Artefakte und Bild Verschlechterung führen, ist es sehr zu empfehlen, dass die Anwendung eine kleine Reihe von Bildressourcen, die verschiedene häufig verwendete dpi Einstellungen umfassen. Wenn keine exakte Übereinstimmung gefunden wird, wird das nächste Bild hoch- oder herunterskaliert.

Um dies zu erleichtern, können Bildressourcen in Ribbon Markup deklariert werden, indem für jedes Command-Element eine Reihe von Image-Elementen verwendet wird. Bei Laufzeit Zeit wählt das Framework das anzuzeigende Bild basierend auf dem Attribut MinDPI jedes Image-Elements aus.

Unten befindet sich ein Beispiel.

Answer 2

Problem gelöst: Konfiguration -> Manifest Tool -> Ein- und Ausgang -> Aktivieren DPI Awareness NO

NO, ist die Lösung. Der Standardwert ist leider JA.