Recherche avancée

Sur d’autres sites (5340)

• libavutil/hwcontext_qsv : add usage child_device_type argument to explicitly select...

  20 août 2021, par Artem Galin

  libavutil/hwcontext_qsv : add usage child_device_type argument to explicitly select d3d11va/DX11 device type
  UPD : Rebase of last patch set over current master and use DX9 as default device type.
  Makes selection of dxva2/DX9 device type by default as before with explicit d3d11va/DX11 usage to cover more HW configurations.
  
  Added warning message to expect changing default device type in the future.
  Fixes TGL / AV1 decode as requires DX11 with explicit DX11 type
  
  selection.
  Add headless/multi adapter support and fixes :
  
      https://trac.ffmpeg.org/ticket/7511
  
      https://trac.ffmpeg.org/ticket/6827
  
      http://ffmpeg.org/pipermail/ffmpeg-trac/2017-November/041901.html
  
      https://trac.ffmpeg.org/ticket/7933
  
      https://github.com/InitialForce/FFmpeg/commit/338fbcd5bba1de0e1b3e3bad8985eee2fdfbeca1
  
      https://github.com/jellyfin/jellyfin/issues/2626#issuecomment-602153952
  Any other fixes are welcome including OpenCL interop patch since I don't have proper setup to validate this use case
  Decoding, encoding, transcoding have been validated.
  child_device_type option is responsible for d3d11va/dxva2 device selection
  Usage examples :
  DirectX 11 :
  
      -init_hw_device qsv:hw,child_device_type=d3d11va
  
      -init_hw_device qsv:hw,child_device_type=d3d11va,child_device=0
  
  OR
  
      -init_hw_device d3d11va=dx -init_hw_device qsv@dx
  DirectX 9 is still supported but requires explicit selection :
  
      -init_hw_device qsv:hw,child_device_type=dxva2
  
  OR
  
      -init_hw_device dxva2=dx -init_hw_device qsv@dx
  Signed-off-by : Artem Galin <artem.galin@intel.com>
  

  • [DH] doc/ffmpeg.texi
  • [DH] libavutil/hwcontext_qsv.c

• Evolution #4841 (Fermé) : Z-index de la modale

  2 juillet 2021

  Bonjour,

  Le ticket https://git.spip.net/spip-contrib-extensions/crayons/issues/9 montre qu’il peut y avoir 2 cas d’usage d’une modale-box et des crayons :

  1. un crayon qui appelle une modale (comportement qui fonctionne depuis des années avec le plugin Insérer Modèles)
  2. une modale qui contient un crayon

  C’est ce 2e cas qui provoqué ce commit https://git.spip.net/spip-contrib-extensions/crayons/commit/f1c7f89a115eda2bc166ce50a76c5b1e9d01a3a7
  Commit qui casse le premier cas

  Proposition de piste de solution : est-ce qu’il serait possible à la modale box de s’adapter automagiquement et d’avoir un z-index dynamique qui serait égal au z-index actuel maximum de la page + 1 ?

  La question du z-index max d’une page a plein de réponses : https://www.google.com/search?q=javascript+get+highestindex+on+page

  • https://awik.io/make-sure-element-highest-z-index/
  • https://www.willmaster.com/blog/javascript/z-index-range.php
  • https://www.sitepoint.com/jquery-find-highest-z-index-page/
  • https://blog.frankmtaylor.com/2019/05/16/whats-the-highest-z-index-on-a-page-and-other-css-property-problems/ (la plus complexe, mais la mieux expliquée)

• Evolution #4727 (Nouveau) : Des pictos / icônes symboliques pour tout le monde

  12 avril 2021

  Je fais un ticket pour la future PR et poser le plan d’action.
  C’est la suite de https://core.spip.net/issues/4562#Des-ic%C3%B4nes

  Proposition pour intégrer un jeu complet d’icônes symboliques.¶

  Les besoins sont multiples pour pleins d’éléments d’interface, dans le core et les plugins : des barres d’outils, des boutons d’actions, etc.
  Et chacun doit réimplémenter ça un peu à sa sauce, notamment dans le privé.

  C’est un besoin bien distinct des icônes svg de couleur dont on dispose actuellement dans le privé : on veut des pictos symboliques qui héritent de taille et de la couleur du texte, et issus d’un même set afin d’avoir un style unifié.
  Cela vient donc en complément.

  Il s’agit donc de reprendre un jeu d’icônes existant, qu’on n’aura pas à maintenir, optimisé, et qui fournit des icônes cohérentes visuellement, utilisables dans tous les contextes. Cf. plus bas pour une comparaison initiale des candidats possibles.

  Utilisation¶

  Ces icônes seraient utilisables de 2 façons :

  1) Des classes .spicon¶

  Des classes à ajouter à n’importe quel élément inline quand il s’agit d’icônes purement décoratives.
  Ces classes pouvant finir dans squelettes utilisés dans le public, pour éviter les conflits, on propose la contraption de spip + icon = spicon. Il y a aussi spip-icon mais c’est un peu plus verbeux.

  Exemples :

  <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_menu</span><span class="delimiter">"</span></span><span class="tag">></span>Ouvrir le menu<span class="tag"></span>
  
  <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_truc</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag"></span> Du texte
  
  <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">titrem spicon_machin</span><span class="delimiter">"</span></span><span class="tag">></span>Mon titre<span class="tag"></span>
  
  </span></span></span></span>

  2) Une balise #ICON¶

  En complément, on peut vouloir embarquer une icône svg dans le HTML.

  On propose de reprendre et d’adapter la balise #ICON du plugin Zcore, qui fait ça très bien.
  Cette balise permet d’embarquer une icône du set par défaut, mais également n’importe quelle autre (je rentre pas dans les détails).

  Un modèle correspondant permettra aussi d’inclure des icônes svg dans les textes :
  

  <span class="CodeRay">
  
  #ICONE{identifiant}
  
  #ICONE{chemin/vers/mon_icone.svg}
  
  #ICONE{#identifiant_autre_set}
  
  </span>

  Identifiants sémantiques¶

  Les identifiants des icônes seront directement ceux du jeu d’icônes choisi.
  Mais ils peuvent avoir des noms un peu barbares : chevron-double-right, eye-slash, grip-vertical, etc.

  Dans tous les cas on pourra les utiliser tels quels, mais en plus de ça, on propose de faire une correspondance sémantique pour les icônes correspondants aux actions les plus courantes. Par exemple au lieu de faire #ICONE{chevron-double-down} on pourra faire #ICONE{deplier}.
  Cela passerait par un pipeline, donc liste qui peut être complétée selon ses besoins.

  La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both

  Ressources privé / public¶

  Cela veut dire 2 ressources à charger :

  • Une font-face pour les classes
  • Un sprite svg pour la balise

  Dans le privé, il faut charger les 2.
  Dans le public, cela pourrait se faire optionnellement, à la demande.

  Candidats¶

  Pour finir un tableau comparatif des jeux d’icônes possibles (à licences libres), avec mes commentaires initiaux.
  Petite préférence pour Feather actuellement.

  Lib	Nb	sprite	fontface	Commentaire
  Bootstrap	1300+	693ko	85ko	Clés en main, beaucoup d’icônes (trop ?)
  Feather	286	( 100ko)	-	Styles rounded. Bonne balance nb icônes / poids.
  Octicon (Github)	433	( 240ko)	-	Styles rounded. Bonne balance nb icônes / poids. Beaucoup de manips à faire pour créer sprite et cie.
  Material (Google)	?	(?ko)	44ko	Style rounded / épaisseur variable. Beaucoup de manips à faire pour créer sprite et cie. Google !
  Core-ui	554	418ko	63ko	Clés en main. Sets inutiles non pris en compte dans ce tableau (brands, flags, …)
  Bytesize	101	11ko	-	Style rounded / épaisseur variable. Léger : le minimum syndical.

  Sprite entre parenthèses = non fourni dans le dépôt ou la dist → poids théorique.