Rendering PDF Content in Windows Store Apps (3-175)

Session animée par Chetan Parulekar

WinRT possède maintenant une api qui permet de rendre tout ou partie des pages d’un PDF sous la forme d’images.

On commence par une démo (plutôt classe) d’une application JavaScript qui permet de lire une liste d’articles en PDF.

L’API permet de récupérer les méta données du document et d’une page. Les images générées sont rendues en png par défaut. L’API gère les PDF protégés par mot de passe.

On aborde ensuite les options possibles pour le rendu. On peut spécifier la couleur de fond, le format d’image, la taille de destination, la possibilité de faire du High contraste, ou la portion de la page que l’on souhaite rendre. On voit un exemple en xaml et un exemple en js.

On aborde ensuite les best practices associées a cette api. Faire bien attention a libérer les ressources, et en particulier l’objet PDFPage et l’image générée. On voit l’intégration en xaml avec une flipview databindée et la libération du bitmapsource. Par ailleurs, la génération du PDF consomme des ressources. Penser a annuler les rendus si l’utilisateur navigue vite entre les pages. Le temps de rendu est proportionnel a la taille de la zone a rendre, un axe d’optimisation est de ne rendre que les portions visibles.

On termine par un exemple similaire avec DirectX.

Guillaume Leborgne

Windows Runtime Internals: Understanding the Threading Model (4-107)

Session animée par Martyn Lovell

Le but de la session est de présenter pourquoi le threading est important et comment le theading est implémenté dans WinRT et qu’est-ce qui se cache derrière la façade.

La session commence par une démo en C++ nommée « Media Buttons » qui montre tout les threads créés automatiquement par le système.

Pourquoi on a besoin de threads :

  • Services connectés au monde
  • Application responsive
  • Expérience touch
  • Plusieurs cœurs

Comment Windows parallélise :

  • Kernel threads
  • Separate processes
  • Brokers
  • Async operations

 Windows threading model :

  • UI objects dans le thread UI
  • Le thread principal vi aussi longtemps que l’application
  • La plupart des autres objets peuvent être utilisés dans n’importe quel threads
  • La plupart du travail est passé au ThreadPool
  • Les objets Windows suivent des règles naturelles et familières
  • Vous contrôlez la durée de vit d’un thread

 Le thread UI :

  • Les interfaces utilisateurs ont des besoin spécians
    • On ne veux pas que OK soit appuyé pendant le OnCancel
  • Les objet UI sont naturellement sérialisés
  • Ne pas faire de long travail sur le thread UI
  • A la place il faut passer un maximum de travail au thread pool

Demo : Comportement du thread UI

 UI Thread reentrency :

  • Les objets sur le thread UI n’ont pas besoin de locking pour se protéger eux-mêmes
  • Les thread UI ne sont pas réentrants
  • Quand vous faite un appel à un autre thread/process, seul les threads logiquement connectés peuvent vous rappeler
  • Les threads UI ne peuvent pas s’appeler en même temps (rejeté au moment de l’appel dans Windows 8.1)
  • Utiliser un dispatcher ou un objet asynchrone pour éviter ce genre d’appels

Schéma d’explication du « Single-threaded apartment reentrancy ».

 UI Thread waiting :

  • Pas de délais autorisés sur les threads UI
  • Most classic waiting primitives are inappropriate (Windows tue les applications ne répondant plus)
  • A la place il faut appeler des primitives UI-safe (C# await, C++ create_task, JS promise)

Démo : Safe view shutdown (MultipleView Sample)

 Le UI thread Principal :

  • L’interface principale de l’application est toujours lancée dans le thread UI principal
  • Le thread UI principal est utilisé pour gérer l’état global de l’application
  • Les autres threads UI sont pour les documents et les contrats
  • Le thread UI principal est vivant tant jusqu’à ce que l’application meure

 Threading dans l’environnement HTML :

  • Tout les threads sont des threads UI (même les web workers sont single-threaded)
  • Tout les évènement et complétions sont délivrées là où elle ont commencées
  • Utilisez les api standard des applications web au lieu du WinRT Core*

Threading en XAML :

  • Les objets UI sont liés à un threads
  • Utilise le dispatcher to déplacer le travail de l’ui dans le thread UI
  • Tout l’arbre XAML est dans un seul thread
  • Les évènements sont dans le thread UI

Objects and threading

  • Les protocoles basiques de WinRT sont threading-agnostic (Iunknown, Iinspectable)
  • La plupart des objets WinRT n’ont pas besoin de marshaling
  • Même les références à des objets hors du processus (proxies) sont agiles dans WinRT
  • Donc même si le marshaling existe toujours il est rarement visible et ce délibérément

Marshaling :

  • Les objet décident comment ils se marshallent (IMarshal, INoMarshal contrôlent le marshalling)
  • Les objets WinRT généralement « opt-out of marshaling »
  • Tout les marshalers sont fournis par le système avec l’aide des données générés par le MIDL

Thread pool threads :

  • Là où le travail long est effectué
  • Ils sont alloués, étendues et schedulés par le système
  • Les opérations async de WinRT tournent générallement dedans
  • Toujours initialisés par WinRT

Schéma démo des callback sur des objets asynchrones

Les objets agiles :

  • Objets qui peuvent travailler dans n’importe quel thread ou process sans être marshalled
  • Ils ne peuvent stocker que des objets agiles
  • Pas de stockage de Iinspectables
  • Ils sont simple à manipuler
  • La plupart des objets WinRT sont agiles

Apartments :

  • Apartments sont des concepts COM qui groupent et contrôlent les durés de vie des objets
  • Ils existent dans WinRT mais sont maintenant largement inutiles et remplacés par les objets agiles
  • Trois apartment
    • ASTA
    • MTA
    • NTA (Neutral threaded apartment utilisés par WinRT)

Appels cross-threads :

  • Les appels WinRT sont délivrés seulement quand le thread est prêt
  • Les appels sont en compétitions avec les autres pour obtenir l’attention d’un thread
  • Win 8.1 change :
    • Les appels ne bloquent plus les input
    • Le scheduler autorise les priorisation des work items

Une session intéressante qui explique tout ce qui se passe dans WinRT au niveau du threading. Définitivement à voir et à revoir.

John Thiriet

Securing Windows Store Applications and REST Services with Active Directory (3-518)

Session animée par Vittorio Bertocci

L’objectif de la session est de montrer comment sécuriser son app avec un AD on-premise ou dans Azure (du coup dans un contexte business).

Comment faire face aux ressources déportées en dehors du réseau interne, aux apps dans le cloud qui ont besoin de l’AD, au BYOD ou aux devices hors domaine… sans rendre fou l’IT ?

# Accéder aux ressources hors du réseau d’entreprise

Il  commence par expliquer les principes d’un serveur d’authentification avec un endpoint d’authentification + un endpoint  de jeton d’accès qu’on pourra ensuite utiliser pour accéder aux ressources.

Puis les jetons de refresh pour ne pas avoir à redemander ses credentials à l’utilisateur toutes les 5 minutes.

On passe maintenant à Windows Azure Active Directory qui, dans un contexte business, sera une projection de votre AD on-premise.

Azure AD dispose :

  • de différents endpoints d’authentification : OAuth2, SAML, WS-Federation, Metadata
  • un portail web de gestion des comptes
  • une API Graph pour récupérer les permissions

Début des démos.

1ère démo : présentation de la gestion de l’AD sur le portail Azure avec la configuration d’une app

2ème démo : une app de test pour montrer les différents types d’appels

Windows Server 2012 R2 ADFS supporte maintenant OAuth2.

# Authentification et session

Windows Azure Authentication Library (AAL) pour aider le développeur pour gérer les échanges de token , le cache… Dispo via un package NuGet.

AAL fonctionne avec Windows Azure AD et Windows Server ADFS.

On nous montre les quelques lignes de codes pour un appel sécurisé depuis une app Win8 (récupération d’un token et appel d’un service REST avec ce token).

AAL wrappe le WebAuth broker. Nouveauté avec Win8.1 on a la possibilité d’implémenter la sélection d’un compte dans les settings (plus de details dans la session 3-113)

# Device hors domaine

Nouveauté 8.1 : Workplace-join pour configurer un accès à un AD qu’on peut ensuite utiliser dans une app

On est en retard, les slides vont très vite…

Session intéressante, à creuser pour voir comment mettre tout ça en œuvre.

Pierre-Yves Hemery

App Performance: The Windows Performance Toolkit (3-100)

Session animée par Chell Sterioff

Objectif : se familiariser avec les outils d’analyses d’applications

Outils d’analyse de performance :

  • Visual Studio
  • Windows performance Toolkit
    • Windows Performance Recorder
    • Windows Performance Analyser

Démo de présentation du recorder et quelles sont les différentes options à notre disposition.

Démo de présentation de tout ce que présente l’analyseur et de la logique à utiliser pour diagnostiquer correctement des problèmes de performance.

Une session très orientée démo et assez difficile à suivre qui dans une certaine mesure entre en conflit avec précédente. La principale difference étant que celle-ci est orienté HTML alors que la précédente était XAML. A voir mais surement plusieurs fois et en plusieurs fois.

John Thiriet

Create Fast and Fluid Interfaces with HTML and JavaScript (3-156)

Session animée par Paul Gildea

Session traitant des perfs et notamment de comment gérer le chargement des apps et des écrans, d’une façon générale et avec les nouvelles API.

UI responsiveness

Un des enjeux est de prioriser des opérations sans lien pour ne pas bloquer le thread UI. Le contrôle Scheduler permet de gérer cette problématique. Le Scheduler permet de définir des priorités sur les traitements. Le Scheduler fonctionne comme un setImmediate.

Consommation mémoire

Winjs implémente un mécanisme de  libération mémoire similaire a celui de .net avec une méthode dispose. Les contrôles qui supportent ce pattern ajoute une classe css “win-disposable”, et doivent libérer les contrôles enfant avec winjs.utilities.disposeSubTree. Le controle Navigator présent dans les templates projet implémente tout cela.

Longues listes

Le point principal concerne le rendu des items. Les contrôles winjs sont responsables du déclenchement de ce rendu. Avec winjs 2 les templates sont compilés, ce qui améliore les perfs. Les templates permettent aussi de libérer la mémoire (disposable). Une option du Template peut le rendre debuggable.

Temps de démarrage

Pour commencer, faire attention à la structure du html car cela impacte le temps de chargement. Le Scheduler permet aussi d’améliorer le chargement (en utilisant une methode requestDrain qui force l’exécution des traitements de la priorité ciblée).

Guillaume Leborgne

XAML performance fundamentals (3-157)

Session animée par Kiran Kumar

On commence par une petite piqure de rappel sur ce que signifie la performance

  • Fluidité
  • Rapidité
  • Impression des utilisateurs

Ensuite on parle de ce qu’il faut savoir

  • Connaître le runtime
  • Connaître son budget (CPU ou temps de développement)
  • Utilisation de pattern (MVVM)

Rappel/présentation sur l’architecture de XAML et les différents threads qui le compose.

Description du cycle de vie d’une frame XAML.

Description du démarrage d’une application en XAML et de ce qui cause des ralentissements.

S’ensuit une démonstration de comment on peu diagnostiquer ce genre de soucis de démarrage et de parsing de xaml (utilisation de wprui et wpa avec un profil spécialisé pour l’analyse du XAML)

Rappels sur les animations dépendantes et indépendantes et que les animations dépendantes ralentissent sont soumises au CPU et non au GPU.

Nouvelles api de diagnostics : DebugSettings.EnableFrameRateCounter, DebugSetting.EnableRedrawRegions, DebugSettings.IsOverdrawHeatMapEnabled

Description du fonctionnement des animations de panning et pastes d’améliorations pour l’affichage des contenus virtualisés.

Présentation d’une nouvelle api GridView.ContainerContentChanging qui permet d’éviter le coût du databinding en donnant la main à l’utilisateur pour qu’il remplisse les éléments du GridView.

Démo diagnostic des problèmes d’animations et de panning.

On parle ensuite des médias et de la manière d’optimiser leurs performance.

Présentation des améliorations :

  • Démarrage plus rapide
  • Templates par défuts meilleurs
  • Support du XAML binaire
  • Databinding plus rapide
  • Utilisation mémoire inférieure
  • Grouping Panning 2x plus rapide
  • Nouvelle api pour les panels
  • Etc…

Comme l’année dernière Kiran Kumar a fait une belle session rentrant bien dans les détails du moteur de XAML et montrant les nouveautés du Windows Performance Analyser

John Thiriet

Fast Apps and Sites with JavaScript (4-313)

Session animée par Gaurav Seth

Session sur comment faire ou améliorer les perfs de nos codes JavaScript.

Les démos présentées sont disponibles ici :

http://aka.ms/fastjs

http://aka.ms/fasterjs

On attire notre attention sur le fait que le browser est en single thread donc pour atteindre 60fps, les traitements doivent prendre moins de 16ms sinon on a du flickering. JavaScript est très flexible et permet toujours plusieurs façons très différentes de faire quelque chose, donc il faut être vigilant car certains mauvais usages ont des impacts importants sur les perfs.

Le premier point abordé est de faire attention aux allocations d’objet. L’allocation elle même n’est pas très couteuse mais elle implique de la garbage collection. Si on doit manipuler beaucoup d’objets, on peut par exemple faire des pools d’objets.

JavaScript permet de faire des objets avec des propriétés dynamiques, mais les interpréteurs infèrent des types. Il est préférable d’initialiser toutes les propriétés des objets, même celles qui ne sont pas utilisées. Le moteur peut ainsi optimiser le type. L’utilisation du mot clé delete, ou l’ajout de propriétés à la volée, ou le fait de changer le type d’une propriété empêchent aussi le moteur d’optimiser le type. L’utilisation des accesseurs sur les propriétés est également plus lent. De la même façon, il est préférable d’avoir un format homogène sur les données stockées dans les tableaux. L’idéal est d’utiliser les array typées (Float64Array). Pour itérer sur les tableaux, le plus efficace est une boucle for, a condition de ne pas faire un .length dans le for (faire une variable).

En JavaScript les nombres sont par défaut des double en 64bits. Le moteur peut améliorer les perfs si il peut être sûr de pouvoir stocker une variable sous la forme d’un nombre entier.
Le dernier point est de prendre garde aux appels au DOM. Il est souvent préférable de créer une variable intermédiaire (sur la propriété style par exemple).

Guillaume Leborgne