Optimalizace animací, médií a obrázků

Vytvářejte aplikace WinUI pomocí hladkých animací, vysoké frekvence snímků a vysoce výkonného zachytávání a přehrávání médií.

Vyhlazení animací

Klíčovým aspektem aplikací WinUI je hladké interakce. To zahrnuje manipulace s dotykovým ovládáním, které se "drží prstem", hladké přechody a animace a malé pohyby, které poskytují zpětnou vazbu. V rozhraní XAML existuje vlákno označované jako vlákno složení, které je vyhrazené pro složení a animaci vizuálních prvků aplikace. Vzhledem k tomu, že vlákno složení je oddělené od vlákna uživatelského rozhraní (vlákno, které spouští architekturu a kód pro vývojáře), můžou aplikace dosáhnout konzistentní frekvence snímků a hladkých animací bez ohledu na složité průchody rozložení nebo rozšířené výpočty. V této části se dozvíte, jak pomocí vlákna kompozice postarat se o hladký chod animací aplikace. Další informace o animacích najdete v tématu Přehled animací. Další informace o zvýšení rychlosti odezvy aplikace při provádění náročných výpočtů najdete v tématu Zachování odezvy vlákna uživatelského rozhraní.

Používejte nezávislé animace místo závislých

Nezávislé animace se dají vypočítat od začátku do konce v době vytváření, protože změny animace vlastnosti neovlivní zbytek objektů ve scéně. Nezávislé animace se proto můžou spouštět ve vlákně složení místo vlákna uživatelského rozhraní. To zaručuje, že zůstanou hladké, protože se kompoziční vlákno aktualizuje v konzistentním tempu.

U všech těchto typů animací je zaručeno, že budou nezávislé:

Závislé animace ovlivňují rozložení, které proto nelze vypočítat bez dodatečného vstupu z vlákna uživatelského rozhraní. Závislé animace zahrnují úpravy vlastností, jako je Šířka a Výška. Ve výchozím nastavení nejsou závislé animace spuštěné a vyžadují výslovný souhlas od vývojáře aplikací. Pokud je povoleno, běží hladce, pokud vlákno uživatelského rozhraní zůstane odblokované, ale začnou se zasekávat, pokud rámec nebo aplikace provádí spoustu dalších prací na vlákně uživatelského rozhraní.

Téměř všechny animace v rámci XAML jsou ve výchozím nastavení nezávislé, ale existuje několik akcí, které můžete provést, abyste tuto optimalizaci zakázali. Dávejte pozor zejména na tyto scénáře:

  • Nastavení vlastnosti EnableDependentAnimation k umožnění spuštění závislé animace ve vlákně uživatelského rozhraní. Převeďte tyto animace na nezávislou verzi. Animujte například ScaleTransform.ScaleX a ScaleTransform.ScaleY místo Width a Height objektu. Nebojte se škálovat objekty, jako jsou obrázky a text. Rámec používá bilineární škálování pouze během animace ScaleTransform. Obrázek/text bude přerasterizován na konečnou velikost, aby se zajistilo, že budou vždy jasné.
  • Provádění aktualizací jednotlivých snímků, což jsou efektivně závislé animace. Příkladem je použití transformací v obslužné rutině události CompositionTarget.Rendering.
  • Spuštění jakékoli animace, která je považována za nezávislou v elementu s vlastností CacheMode nastavenou na BitmapCache. To je považováno za závislé, protože mezipaměť musí být znovu převedena na rastrový formát pro každou snímku.

Neanimujte WebView2 ani MediaPlayerElement

Webový obsah hostovaný v ovládacím prvku WebView2 není vykreslen přímo rozhraním XAML, takže jeho vytvoření se zbytkem scény vyžaduje další práci. Tato režie se sčítá, když animujete ovládací prvek po obrazovce a může docházet k problémům se synchronizací, například pokud se zdá, že se webový obsah přesune mimo synchronizaci s okolním XAML. Pokud potřebujete animace kolem webového obsahu, animujte okolní prvky rozhraní WinUI místo samotné plochy WebView2. Dřívější pokyny můžou zmínit WebViewBrush; v moderních aplikacích WinUI je WebView2 podporovaný ovládací prvek pro hostování webu a neexistuje žádná přímá náhrada WebViewBrush.

Animace MediaPlayerElement je podobně špatný nápad. Kromě poškození výkonu může způsobit trhání obrazu nebo jiné artefakty v obsahu videa, který je přehráván.

Nekonečné animace používejte střídmě

Většina animací se spouští po určitou dobu, ale nastavení vlastnosti Timeline.Duration na hodnotu Forever umožňuje, aby se animace běžela neomezeně dlouho. Doporučujeme minimalizovat použití nekonečných animací, protože neustále spotřebovávají prostředky procesoru a můžou zabránit tomu, aby procesor přešel do nízkého výkonu nebo nečinného stavu, což by mohlo způsobit rychlejší výpadky výkonu.

Přidání obslužné rutiny pro CompositionTarget.Rendering se podobá spuštění nekonečné animace. Obvykle je vlákno uživatelského rozhraní aktivní pouze v případě, že je k dispozici práce, ale přidání obslužné rutiny pro tuto událost vynutí spuštění každého rámce. Odstraňte obslužný program, když není třeba žádná práce, a zaregistrujte jej znovu, až bude opět potřeba.

Použití knihovny animací

Obor názvů Microsoft.UI.Xaml.Media.Animation obsahuje knihovnu vysoce výkonných, hladkých animací, které mají vzhled a chování konzistentní s ostatními animacemi windows. Příslušné třídy mají ve svém názvu "Motiv" a jsou popsány v přehledu animací. Tato knihovna podporuje řadu běžných animačních scénářů, jako je animace prvního zobrazení aplikace a vytváření přechodů stavu a obsahu. Tuto animační knihovnu doporučujeme používat, kdykoli je to možné, abyste zvýšili výkon a konzistenci aplikací WinUI.

Poznámka Knihovna animací nemůže animovat všechny možné vlastnosti. Scénáře XAML, ve kterých se knihovna animací nepoužívá, najdete v tématu Scénáře animace.

Animujte každou vlastnost CompositeTransform3D nezávisle na sobě

Jednotlivé vlastnosti CompositeTransform3D můžete animovat nezávisle, takže použijte jenom animace, které potřebujete. Příklady a další informace najdete v tématu UIElement.Transform3D. Pro více informací o animaci transformací, viz Animace s příběhovou linií a animace pomocí klíčových snímků a uvolňovacích funkcí.

Optimalizace mediálních prostředků

Zvukové, video a obrázky jsou poutavé formy obsahu, které většina aplikací používá. S nárůstem míry zachytávání médií a přesunem obsahu ze standardní definice do vysoké definice se zvyšuje množství prostředků potřebných k ukládání, dekódování a přehrávání tohoto obsahu. Architektura XAML vychází z moderní infrastruktury médií windows, takže aplikace WinUI zdědí mnoho z těchto vylepšení automaticky. Tady je několik dalších triků, které vám pomůžou získat maximum z médií v aplikaci WinUI.

Uvolnění streamů médií

Mediální soubory jsou jedněmi z nejběžnějších a nejdražších zdrojů, které aplikace typicky používají. Vzhledem k tomu, že prostředky multimediálních souborů můžou výrazně zvětšit paměťový profil aplikace, nezapomeňte uvolnit popisovač médií, jakmile aplikace dokončí jeho používání.

Pokud například vaše aplikace pracuje s Objektem RandomAccessStream nebo IInputStream , nezapomeňte při jeho použití volat metodu zavření objektu, aby se uvolnil základní objekt.

Zobrazení přehrávání videa na celé obrazovce, pokud je to možné

V aplikacích WinUI vždy používejte vlastnost IsFullWindow na MediaPlayerElement a povolte a zakažte úplné vykreslování oken. Tím zajistíte, že se při přehrávání médií použijí optimalizace na úrovni systému.

XAML framework může optimalizovat zobrazení video obsahu, když je jedinou věcí, která se vykresluje, což vede k nižší spotřebě energie a vyšším frekvencím snímků. Pro nejúčinnější přehrávání médií nastavte velikost MediaPlayerElement na šířku a výšku obrazovky a nezobrazovat další prvky XAML.

Existují oprávněné důvody k překrytí prvků XAML na MediaPlayerElement, které zabírají plnou šířku a výšku obrazovky, například skryté titulky nebo dočasné ovládací prvky přehrávání. Nezapomeňte tyto prvky (set Visibility="Collapsed") skrýt, pokud nejsou potřeba k přehrání médií zpět do nejúčinnějšího stavu.

Vypnutí displeje a úspora energie

Pokud chcete zabránit deaktivaci zobrazení, když se už nezjistí akce uživatele, například když aplikace přehrává video, můžete volat DisplayRequest.RequestActive.

Pokud chcete ušetřit energii a výdrž baterie, měli byste zavolat DisplayRequest.RequestRelease , aby se žádost o zobrazení uvolnila, jakmile už není vyžadována.

Tady je několik situací, kdy byste měli vydat žádost o zobrazení:

  • Přehrávání videa je pozastaveno, například akcí uživatele, ukládáním do vyrovnávací paměti nebo úpravou kvůli omezené šířce pásma.
  • Přehrávání se zastaví. Video se například přestalo přehrávat, nebo prezentace skončila.
  • Došlo k chybě přehrávání. Například problémy s připojením k síti nebo poškozený soubor.

Umístěte další prvky na stranu vloženého videa.

Aplikace často nabízejí vložené zobrazení, ve kterém se video přehrávala na stránce. Nyní jste zřejmě ztratili optimalizaci na celou obrazovku, protože MediaPlayerElement nemá velikost stránky a jsou tam vykresleny další objekty XAML. Dávejte pozor na neúmyslné vstupy do tohoto režimu tím, že kolem MediaPlayerElement nakreslíte ohraničení.

Nevykreslujte prvky XAML nad videem, když jsou v integrovaném režimu. Pokud to uděláte, architektura je nucena udělat trochu další práce pro vytvoření scény. Umístění ovládacích prvků přehrávání pod vložený mediální prvek namísto na vrch videa je dobrým příkladem optimalizace pro tuto situaci. Na tomto obrázku červený pruh označuje sadu ovládacích prvků přenosu (přehrávání, pozastavení, zastavení atd.).

MediaPlayerElement s překryvnými prvky

Tyto ovládací prvky neumisťujte na médium, které není na celé obrazovce. Místo toho umístěte ovládací prvky pro přehrávání médií někam mimo oblast, kde se médium zobrazuje. Na dalším obrázku se ovládací prvky umístí pod médium.

MediaPlayerElement se sousedními prvky

Zpoždění nastavení zdroje pro MediaPlayerElement

Multimediální moduly jsou nákladné objekty a architektura XAML zpožďuje načítání knihoven DLL a vytváření velkých objektů co nejdéle. MediaPlayerElement je nucen provést tuto práci poté, co je jeho zdroj nastaven prostřednictvím vlastnosti Source. Nastavením této možnosti, když je uživatel skutečně připraven přehrávat média, se většina nákladů spojených s MediaPlayerElement odloží na co nejdelší dobu.

Nastavení MediaPlayerElement.PosterSource

Nastavení MediaPlayerElement.PosterSource umožňuje XAML uvolnit některé prostředky GPU, které by jinak byly použity. Toto rozhraní API umožňuje aplikaci používat co nejmenší paměť.

Vylepšení čištění médií

Scrubbing je vždy náročný úkol pro mediální platformy, aby skutečně reagovaly. Lidé toho obvykle dosahují tím, že změní hodnotu posuvníku. Tady je několik tipů, jak tento postup co nejefektivněji zajistit:

  • Aktualizujte hodnotu Posuvník na základě časovače, který se dotazuje na Pozici na MediaPlayerElement.MediaPlayer. Ujistěte se, že pro časovač používáte přiměřenou frekvenci aktualizací. Vlastnost Position se během přehrávání aktualizuje pouze každých 250 milisekund.
  • Velikost frekvence kroku na posuvníku se musí škálovat s délkou videa.
  • Přihlaste se k odběru událostí PointerPressed, PointerMoved, PointerReleased na posuvníku a nastavte vlastnost PlaybackRate na hodnotu 0, když uživatel přetáhne posuvník.
  • V obslužné rutině události PointerReleased ručně nastavte umístění média na hodnotu pozice posuvníku, abyste dosáhli optimálního přichycení palce při čištění.

Porovnání rozlišení videa s rozlišením zařízení

Dekódování videa trvá hodně paměti a cyklů GPU, takže zvolte formát videa blízko rozlišení, na kterém se zobrazí. Použití prostředků k dekódování videa 1080p nemá smysl, pokud se má zmenšit na mnohem menší velikost. Mnoho aplikací nemá stejné video kódované v různých rozlišeních; ale pokud je k dispozici, použijte kódování, které je blízko rozlišení, ve kterém se zobrazí.

Výběr formátu médií může být citlivým tématem a často se řídí obchodními rozhodnutími. Z hlediska výkonu sady Windows App SDK doporučujeme video H.264 jako primární formát videa a AAC a MP3 jako upřednostňované formáty zvuku. Pro přehrávání místních souborů je mp4 upřednostňovaným kontejnerem souborů pro videoobsáh. Dekódování H.264 se akceleruje prostřednictvím nejnovějšího grafického hardwaru. Ačkoliv je akcelerace prostřednictvím hardwaru pro dekódování VC-1 široce dostupná, u velké sady grafických karet na trhu je akcelerace v mnoha případech omezena na částečnou úroveň akcelerace (nebo úroveň IDCT) namísto plného hardwarového offloadu (to znamená režimu VLD).

Pokud máte úplnou kontrolu nad procesem generování obsahu videa, musíte zjistit, jak zajistit dobrou rovnováhu mezi efektivitou komprese a strukturou GOP. Relativně menší velikost GOP s B snímky může zvýšit výkon při hledání nebo v trikových režimech.

Pokud zahrnete krátké zvukové efekty s nízkou latencí, například ve hrách, používejte soubory WAV s nekomprimovanými daty PCM, abyste snížili režii zpracování, která je typická pro komprimované formáty zvuku.

Optimalizace obrazových prostředků

Škálování obrázků na odpovídající velikost

Obrázky se zaznamenávají ve velmi vysokém rozlišení, což může vést k tomu, že aplikace při dekódování dat obrázku a více paměti po načtení z disku využívají více procesoru. Nemá smysl dekódování a uložení obrázku s vysokým rozlišením v paměti, jen proto, aby se zobrazil menší než jeho původní velikost. Místo toho vytvořte verzi obrázku s přesnou velikostí, která bude nakreslena na obrazovce pomocí vlastností DecodePixelWidth a DecodePixelHeight .

Nedělejte toto:

<Image Source="ms-appx:///Assets/highresCar.jpg"
       Width="300" Height="200"/>    <!-- BAD CODE DO NOT USE.-->

Místo toho postupujte takto:

<Image>
    <Image.Source>
    <BitmapImage UriSource="ms-appx:///Assets/highresCar.jpg"
                 DecodePixelWidth="300" DecodePixelHeight="200"/>
    </Image.Source>
</Image>

Jednotky pro DecodePixelWidth a DecodePixelHeight jsou ve výchozím nastavení fyzické pixely. DecodePixelType vlastnost může být použita ke změně tohoto chování: nastavení DecodePixelType na Logical způsobí, že dekódovací velikost automaticky zohlední aktuální měřítko systému, podobně jako u ostatního XAML obsahu. Proto by bylo obecně vhodné nastavit DecodePixelType na Logical , pokud například chcete DecodePixelWidth a DecodePixelHeight shodovat vlastnosti Height and Width ovládacího prvku Obrázek, ve kterém bude obrázek zobrazen. Při použití výchozího nastavení fyzických pixelů je potřeba sami zohlednit aktuální měřítko systému a pokud uživatel změní předvolby zobrazení, měli byste poslouchat oznámení o změnách škálování.

Pokud je decodePixelWidth/Height explicitně nastavená větší než obrázek, aplikace zbytečně využije další paměť ( až 4 bajty na pixel), což je pro velké obrázky rychle nákladné. Obrázek bude také zmenšován pomocí bilineárního škálování, což by mohlo způsobit rozmazaný vzhled při použití velkých faktorů zmenšení.

Pokud jsou DecodePixelWidth/DecodePixelHeight explicitně nastaveny na menší hodnoty než velikost, kterou bude obrázek zobrazen na obrazovce, bude zvětšen a může se zdát pixelovaný.

V případech, kdy nelze předem určit odpovídající velikost dekódování, byste měli využít automatické dekódování správné velikosti v XAML, které se pokusí dekódovat obraz na vhodnou velikost, pokud není explicitně zadán DecodePixelWidth/DecodePixelHeight.

Pokud znáte velikost obsahu obrázku předem, měli byste nastavit explicitní dekódovací velikost. Pokud je zadaná velikost dekódování relativní vzhledem k jiným velikostem elementů XAML, měli byste také ve spojení nastavit DecodePixelType na logickou hodnotu. Pokud například explicitně nastavíte velikost obsahu pomocí Image.Width a Image.Height, můžete nastavit DecodePixelType na decodePixelType.Logical, což použije stejné logické rozměry pixelů jako ovládací prvek Obrázek. Poté můžete explicitně použít BitmapImage.DecodePixelWidth nebo BitmapImage.DecodePixelHeight k řízení velikosti obrázku, čímž lze potenciálně dosáhnout velkých úspor paměti.

Všimněte si, že Při určování velikosti dekódovaného obsahu by se měla zvážit možnost Image.Stretch.

Dekódování správné velikosti

V případě, že nenastavíte explicitní dekódovací velikost, xaml se pokusí uložit paměť dekódováním obrázku na přesnou velikost, která se zobrazí na obrazovce podle počátečního rozložení stránky. Doporučujeme, abyste aplikaci napsali takovým způsobem, jak tuto funkci používat, pokud je to možné. Tato funkce bude zakázána, pokud jsou splněny některé z následujících podmínek.

  • BitmapImage je připojen k živému stromu XAML po nastavení obsahu pomocí SetSourceAsync nebo UriSource.
  • Obrázek je dekódován pomocí synchronního dekódování, jako je SetSource.
  • Obrázek je skrytý nastavením neprůhlednosti na hodnotu 0 nebo viditelnosti na Collapsovaná na hostitelském prvku obrázku, štětci nebo jakémkoli nadřazeném elementu.
  • Ovládací prvek obrázku nebo štětec používá funkci Stretch of None.
  • Image se používá jako NineGrid.
  • CacheMode="BitmapCache" je nastavena na prvek obrázku nebo na jakýkoli nadřazený prvek.
  • Obrazový štětec není obdélníkový (například při použití na obrazec nebo text).

Ve výše uvedených scénářích je nastavení explicitní velikosti dekódování jediným způsobem, jak dosáhnout úspor paměti.

Před nastavením zdroje byste měli vždy připojit BitmapImage k živému stromu. Pokaždé, když je prvek obrázku nebo štětec zadán v kódu, bude to automaticky případ. Příklady jsou uvedeny níže pod nadpisem "Příklady živého stromu". Při nastavování zdroje datového proudu byste se měli vždy vyhnout použití SetSource a místo toho použít SetSourceAsync. Je dobré se vyhnout skrytí obsahu obrázku (s nulovou neprůhledností nebo sbalenou viditelností), zatímco čekáte na vyvolání události ImageOpened. Toto je otázka subjektivního rozhodnutí: Pokud se to provede, nebudete mít prospěch z automatického dekódování v odpovídající velikosti. Pokud vaše aplikace musí zpočátku skrýt obsah obrázku, měla by také nastavit velikost dekódování explicitně, pokud je to možné.

Příklady živého stromu

Příklad 1 (dobrý) – identifikátor URI (Uniform Resource Identifier) zadaný v kódu

<Image x:Name="myImage" UriSource="Assets/cool-image.png"/>

Příklad 2 značek – URI specifikovaný v code-behind.

<Image x:Name="myImage"/>

Příklad 2 zázemí kódu (dobrý) – připojení BitmapImage ke stromu před nastavením jeho UriSource.

var bitmapImage = new BitmapImage();
myImage.Source = bitmapImage;
bitmapImage.UriSource = new Uri("ms-appx:///Assets/cool-image.png", UriKind.RelativeOrAbsolute);

Příklad 2 code-behind (nesprávný) – nastavení UriSource objektu BitmapImage před připojením ke stromu.

var bitmapImage = new BitmapImage();
bitmapImage.UriSource = new Uri("ms-appx:///Assets/cool-image.png", UriKind.RelativeOrAbsolute);
myImage.Source = bitmapImage;

Optimalizace ukládání do mezipaměti

Optimalizace ukládání do mezipaměti platí pro obrázky, které používají UriSource k načtení obsahu z balíčku aplikace nebo z webu. Identifikátor URI se používá k jedinečné identifikaci podkladového obsahu a interně architektura XAML nebude stahovat ani dekódovat obsah vícekrát. Místo toho bude k zobrazení obsahu vícekrát používat software nebo hardwarové prostředky uložené v mezipaměti.

Výjimkou této optimalizace je, že se obrázek zobrazuje několikrát v různých rozlišeních (které je možné explicitně zadat nebo prostřednictvím automatického dekódování správné velikosti). Každá položka mezipaměti také ukládá rozlišení obrázku a pokud XAML nemůže najít obrázek se zdrojovým identifikátorem URI, který odpovídá požadovanému rozlišení, dekóduje novou verzi s danou velikostí. Nebudou však znovu stahovat zakódovaná data obrázků.

V důsledku toho byste při načítání obrázků z balíčku aplikace měli použít UriSource a vyhnout se použití streamu souborů a SetSourceAsync , pokud to není nutné.

Obrázky na virtualizovaných panelech (například ListView)

Pokud je obraz ze stromu odebrán, protože jej aplikace explicitně odstranila, nebo protože je na moderním virtualizovaném panelu a byl implicitně odstraněn při posunu mimo zobrazení, XAML optimalizuje využití paměti uvolněním hardwarových prostředků pro tento obraz, jelikož tyto prostředky už nejsou pro obraz potřeba. Paměť není uvolněna okamžitě, ale je uvolněna během aktualizace snímku, která nastane po jedné sekundě poté, co prvek obrázku již není ve stromu.

V důsledku toho byste se měli snažit používat moderní virtualizované panely k hostování seznamů obsahu obrázků.

Softwarově rasterizované obrázky

Pokud je obrázek použit pro neobdélníkový štětec nebo pro NineGrid, obrázek bude používat softwarovou rasterizační cestu, která obrázek nebude vůbec škálovat. Kromě toho musí uložit kopii image do softwarové i hardwarové paměti. Pokud se například obrázek použije jako štětec pro elipsu, potenciálně velký celý obrázek se uloží interně dvakrát. Při použití NineGridu nebo neobdélníkového štětce by měla vaše aplikace předem škálovat obrázky na přibližnou velikost, které budou vykreslovány.

Načítání obrázků na pozadí pomocí vlákna

XAML má interní optimalizaci, která umožňuje dekódovat obsah obrázku asynchronně na povrch v hardwarové paměti, aniž by vyžadoval zprostředkující povrch v softwarové paměti. Tím se snižuje využití paměti ve špičce a latence vykreslování. Tato funkce bude zakázána, pokud jsou splněny některé z následujících podmínek.

  • Image se používá jako NineGrid.
  • CacheMode="BitmapCache" je nastavena na prvek obrázku nebo na jakýkoli nadřazený prvek.
  • Obrazový štětec není obdélníkový (například při použití na obrazec nebo na text).

SoftwareBitmapSource

Třída SoftwareBitmapSource vyměňuje interoperabilní nekomprimované obrázky mezi různými obory názvů WinRT, jako BitmapDecoder, rozhraní API fotoaparátu a XAML. Tato třída odstraňuje potřebu další kopie, která by obvykle byla nezbytná pro WriteableBitmap, a pomáhá snížit špičkovou paměť a latenci od zdroje k obrazovce.

Objekt SoftwareBitmap, který poskytuje informace o zdroji, lze také nakonfigurovat tak, aby používal vlastní IWICBitmap k zajištění opětovně načítaného úložiště, které aplikaci umožňuje znovu namapovat paměť dle potřeby. Jedná se o pokročilý případ použití jazyka C++.

Vaše aplikace by měla používat SoftwareBitmap a SoftwareBitmapSource k spolupráci s jinými rozhraními API WinRT, která vytvářejí a využívají image. A vaše aplikace by měla používat SoftwareBitmapSource při načítání nekomprimovaných dat obrázků místo použití WriteableBitmap.

Použití metody GetThumbnailAsync pro miniatury

Jedním z případů použití pro škálování obrázků je vytváření miniatur. I když byste mohli použít DecodePixelWidth a DecodePixelHeight k poskytování malých verzí obrázků, Windows poskytuje ještě efektivnější rozhraní API pro načítání miniatur. GetThumbnailAsync poskytuje miniatury obrázků, které už mají systém souborů uložený v mezipaměti. To poskytuje ještě lepší výkon než rozhraní API XAML, protože image nemusí být otevřená ani dekódována.

V aplikaci Windows App SDK inicializujte výběr pomocí úchytu okna aplikace – například uložením hlavního okna jako App.MainWindow.

FileOpenPicker picker = new FileOpenPicker();
var hwnd = WinRT.Interop.WindowNative.GetWindowHandle(App.MainWindow);
WinRT.Interop.InitializeWithWindow.Initialize(picker, hwnd);
picker.FileTypeFilter.Add(".bmp");
picker.FileTypeFilter.Add(".jpg");
picker.FileTypeFilter.Add(".jpeg");
picker.FileTypeFilter.Add(".png");
picker.SuggestedStartLocation = PickerLocationId.PicturesLibrary;

StorageFile file = await picker.PickSingleFileAsync();

StorageItemThumbnail fileThumbnail = await file.GetThumbnailAsync(ThumbnailMode.SingleItem, 64);

BitmapImage bmp = new BitmapImage();
await bmp.SetSourceAsync(fileThumbnail);

Image img = new Image();
img.Source = bmp;

Dekódovat obrázky jednou

Chcete-li zabránit dekódování obrázků více než jednou, přiřaďte vlastnost Image.Source z identifikátoru URI místo použití datových proudů paměti. Architektura XAML může přidružit stejný identifikátor URI na více místech k jedné dekódované imagi, ale nemůže provést totéž pro více datových proudů paměti, které obsahují stejná data, a vytvoří pro každý datový proud paměti jinou dekódovanou image.

  • Last updated on