Chrome fait crasher Final Cut Pro X
Chrome n’est pas le navigateur le plus frugal en ressources, malgré les efforts de Google pour dégraisser le mammouth. On apprend aussi que Chrome est à l’origine de forts ralentissements puis des crashs dans Final Cut Pro X et d’autres logiciels vidéo ! Felipe Baez, le fondateur de l’agence de design et de production vidéo Cre8ivebeast, prévient qu’utiliser le navigateur dégrade fortement les performances de VideoToolBox.
Ce framework bas niveau permet à un logiciel d’exploiter les ressources matérielles du Mac pour l’encodage et le décodage vidéo. Forcément, ce framework est utilisé par Final Cut Pro X, mais aussi par un grand nombre d’applications d’édition vidéo et d’encodage (dont Handbrake). Pour une raison ou pour une autre, Chrome tape dans VideoToolBox et ne le lâche pas, monopolisant ainsi les ressources processeur du Mac.
Lorsque le navigateur se met en tête d’utiliser le framework, son usage du processeur dépasse les 300%, a relevé Baez. Les performances de FCP sont alors très dégradées ; pour retrouver de l’air et un fonctionnement normal, il faut quitter Chrome, ce qui libère VideoToolBox. La manip’ est aussi valable pour tous les logiciels vidéo qui utilisent VideoToolBox.
Chrome, worst navigator after Edge
@belrock
Browser
"Browser" I do confirm!
J'ai eu des problèmes identiques avec Chrome et Premiere.
Après avoir viré Chrome des stations de montage, plus de soucis.
@JoKer
Je confirme.
Pareil !
C'est pire qu'un virus cette chose. Et encore on parle que des perfs, pas du fait que ça balance toute votre vie privée sur les serveurs de la maison mère...
"Et encore on parle que des perfs, pas du fait que ça balance toute votre vie privée sur les serveurs de la maison mère"
Euh, mais c'est pas la fonction première de ce logiciel ?
Le reste n'est-il pas que du remplissage pour faire croire à son utilité ?
Est-ce que le même problème se présente avec les Chrome-like tels que Opera ou Vivaldi ?
@Moonwalker
Et je rajouterais:
Est-ce que le même problème se présente avec les apps basé sur Electron ?
Chrome est très rapide et gère bien les sites lourd (streaming sport - constructeur auto...), mais par contre sa gestion des ressources est anarchique malheureusement...
@malcolmZ07
Chrome est très rapide
En effet, et il fait aussi appel plus souvent au processeur
Une autre façon de dire les choses c'est qu'un composant système de macOS, VideoToolBox, ne gère pas correctement (ou ne propose pas) de manière dynamique par processus l'utilisation de la ressource "accelération matérielle des codecs vidéo".
Mais, alors que tous les services d'OS désormais sont censé gérer l'accès aux ressources systèmes, en particulier matériel, on préfère désigner une application, qui tourne dans l'environnement clos dit "mode utilisateur", surveillé pourtant par l'OS, comme la responsable des faiblesses système.
Diriez-vous la même chose si macOS gérait mal la mémoire virtuelle ? Chrome, demandant beaucoup de mémoire, fait planter FCP X !? Non. La gestion dynamique de la mémoire physique par l'OS est considéré une fonction de l'OS.
L'accès à toute ressource matérielle en théorie aussi.
En particulier quand l'OS fournit bien une interface pour cela (ici, VideoToolBox).
Désolé, mais le problème est dans cette interface système, pas dans les processus en mode utilisateur qui s'en servent.
> il faut quitter Chrome, ce qui libère VideoToolBox.
> La manip’ est aussi valable pour tous les logiciels vidéo qui utilisent VideoToolBox.
Voilà. En gros, il vaut mieux qu'une seul app s'en serve à la fois. Alors pourquoi pointer Chrome plus que tout autre app qui peut utiliser VideoToolBox en même temps que FCP X ?
Le problème c'est la gestion de priorité dans l'usage des accelerations matérielles par VideoToolBox.
Quand FCP X se plante, c'est soit sa propre faute (bug dans le code de l'app) soit de la faute de l'OS (bug dans le code de l'OS ou d'un pilote), soit du matériel (bug dans l'implémentation sur le matos, non prévu par le code de l'OS ou du pilote).
Pointer du doigt un autre programme tournant sur un OS moderne, qui isole par définition chaque programme les uns des autres, c'est franchement une vision anachronique.
@byte_order
Chrome s’accapare les ressources peu importe l’OS. Bizarrement ça me fait penser à ça
Notamment sous windows avec WebGL. Je comprenais pas pourquoi un navigateur pouvais me provoquer autant de glitch dans l’UI de Windows. Normal, il a un accès direct au GPU ?♂️
Chrome (ni aucun autre processus utilisateur) n'obtient des ressources que parce que l'OS l'accepte. Il en réclame beaucoup, en effet, mais dès lors que l'OS le lui accorde, pourquoi devrait-il *ne pas* les utiliser !?
> Normal, il a un accès direct au GPU
Que l'OS lui a accordé.
Et qui passe par des pilotes du système car, non, Chrome ne contient pas du code pour (toutes) les cartes GPUs, non.
Chrome ne court-circuite pas l'OS. Il essaye d'exploiter au maximum les ressources que l'OS accepte de l'autoriser à utiliser. S'il ne le faisait pas, on entendrait des gens râler "pfff, Chrome exploite mal le matos, il décode youtube avec le CPU alors que la GPU est nettement plus rapide pour faire ça, pfff, quels bandes de nazes chez Google....".
@byte_order
"S'il ne le faisait pas, on entendrait des gens râler "pfff, Chrome exploite mal le matos, il décode youtube avec le CPU alors que la GPU est nettement plus rapide pour faire ça, pfff, quels bandes de nazes chez Google...."."
Et si macOS empêchait Chrome d’utiliser un max de ressources, on entendrait aussi les gens (parfois les mêmes) râler que « le mac c’est de la merde, même pas capable de faire tourner YouTube sur Chrome. »
"Et si macOS empêchait Chrome d’utiliser un max de ressources, on entendrait aussi les gens (parfois les mêmes) râler"
Pire, on dirait que Apple entrave le bon fonctionnement du logiciel de collecte de données privées de Google, la navigation sur Internet restant une fonction très largement secondaire a priori !
@Scooby-Doo
> Pire, on dirait que Apple entrave le bon fonctionnement du logiciel de collecte
> de données privées de Google, la navigation sur Internet restant une fonction
> très largement secondaire a priori !
L'immense majorité des données collectées est faite côté serveurs de Google (que vous sembler confondre avec le code d'un navigateur) ou via du code Javascript qui tourne côté navigateur, et ce quelque soit le navigateur en question.
Coller donc un LittleSnitch et comparez donc l'activité réseau de Safari vs Chrome en accédant aux même sites web.
@pat3
Si l'OS refusait de manière arbitraire l'accès à des ressources qu'il autorise aux apps maisons, oui. Mais s'il les refuse parce que y'a déjà une app (que ce soit FCP X ou n'importe quelle autre, peu importe) et que cette ressource n'est pas vraiment partageable, non.
"Alors pourquoi pointer Chrome plus que tout autre app qui peut utiliser VideoToolBox en même temps que FCP X ?"
Titre putaclick et faudrait éviter de dire à la horde de fanboy qui paie le club que le problème vient de chez leur sainte apple, ils pourraient ne pas apprécier et couper le robinet.
Pour leur faire plaisir, et qu'ils continuent à cracher les €, on dit que c'est de la faute au vilain google. En précisant quand même que ça le fait avec a peu près n'importe quel logiciel, on tord la vérité mais on reste journaliste quand même. :)
@mouahaha
Ah encore un gagnant..
On parle d’un navigateur, bizarrement les autres navigateurs de pose pas de problème.
Rien à voir avec tes délires, surtout que si tu regarde un peu plus bas je parle justement d’une mesure de protection de macOS supposé empêcher ce genre de chose de se produire.
Instruit toi, jette un oeil sur le web concernant Chrome et Webgl.
Ah encore un gagnant..
"La manip’ est aussi valable pour tous les logiciels vidéo qui utilisent VideoToolBox."
C'est dans l'article à la toute fin et c'est écrit par le rédacteur de macg... Tu la lu ou tu commentes juste avec ta vision de google hater ?
@mouahaha
Et regarde un peu plus bas tu comprendras que j’explique que macOS est supposé empêcher cela.
Pète un coup.. ?
" j’explique que macOS est supposé empêcher cela."
C'est donc macos qui est mal branlé. Pas chrome, ni un autre soft qui fait usage de VideoToolBox mais bien macos...
Un google hater qui sort pète un coup quand l'os de sa chapelle fait de la merde et qu'il essai quand même de faire porter le chapeau à google, cocasse. :)
@mouahaha
mouahahahahah ?
En fait, quand on lit bien la fin de l'article, je cite :
"Lorsque le navigateur se met en tête d’utiliser le framework, son usage du processeur dépasse les 300%, a relevé Baez. Les performances de FCP sont alors très dégradées ; pour retrouver de l’air et un fonctionnement normal, il faut quitter Chrome, ce qui libère VideoToolBox. La manip’ est aussi valable pour tous les logiciels vidéo qui utilisent VideoToolBox."
La manipulation est valable pour tous les logiciels de vidéo qui utilisent VideoToolBox.
Donc, le module VideoToolBox est peut-être éventuellement au centre de l'origine du problème, comme on dit !
@reborn
> On parle d’un navigateur, bizarrement les autres navigateurs de pose pas de problème.
Les autres navigateurs ne font pas un usage aussi poussé des fonctions avancées offertes par l'OS sur lequel ils tournent. Fatalement, ils génèrent donc moins de situation mettant à genou ces fonctions avancées du système...
> Rien à voir avec tes délires, surtout que si tu regarde un peu plus bas je parle justement
> d’une mesure de protection de macOS supposé empêcher ce genre de chose de se
> produire.
Le fait que cela échoue ne peut donc pas être imputé au processus en mode utilisateur qui sollicite trop les ressources systèmes mais bien à la défaillance du système à empêcher l'abus de ces ressources critiques par un seul processus.
Si Chrome arrive a faire planter un autre logiciel, ça veut dire 3 choses :
- Chrome fait des opérations très lourdes, mais ça on le savais, c'est presque un OS dans l'OS vu ce que gèrent tous les navigateurs aujourd'hui...
- L'autre logiciel (en l’occurrence Final Cut) a un bug, il ne devrait pas planter, même si le processeur est très chargé. Ou alors, c'est la lib VideoToolBox qui a un bug, et elle plante lorsqu'elle a moins de ressources, et ça, ce n'est pas normal.
- L’ordonnanceur du système a également un défaut en laissant un process s'allouer trop de ressources. Çà s'est aussi un problème système plutôt que de Chrome.
En gros, dans les systèmes actuels (OS), un logiciel ne doit théoriquement jamais provoquer le plantage d'un autre. La seule chose qu'il doit pouvoir éventuellement faire est un ralentissement, ou une occupation mémoire importante. C'est l'OS qui doit contraindre chaque process à n'utiliser qu'une partie des ressources processeurs. Pour ce qui est des plantages, il en revient à FCP ou au framework vidéo de bien gérer les ralentissements globaux du système.
@SuperCed
Je pense au processus sous macOS kernel_task qui a pour but de justement empêcher d’autres process de s’accaparer trop de ressources en leur faisait croire que le processeur est plus utilisé qu’il n’y paraît.
Est-ce que la désactivation de l'accélération matérielle dans Chrome peut éviter ce problème ?
Très probablement, oui.
Chrome en même temps, quelle idée d’utiliser ce truc...
Ben c'est le seul et unique logiciel avec lequel on est quasiment sûr et certain d'envoyer toute sa vie privée à la maison mère.
C'est totalement rassurant...
A part Chrome, je vois bien un certain Facebook qui pourrait lui faire de l'ombre.
Mais en fait, je les trouve tous les deux assez complémentaires, comme ma mutuelle !
C'est une vision un peu ancienne des OS toutes ces remarques. Un peu comme si les applications étaient aux ordres du système. C'était important sur les serveurs multi-utilisateur d'ailleurs.
Mais sur les ordinateurs personnels, il est normal qu'une application puisse demander des ressources exclusives pour aller plus vite (accès au GPU, demander de ne pas swapper...). Les éditeurs de système ajoutent de plus en plus de possibilités de ce genre pour être concurrentiel. Le modèle à papa où tout passe par une attribution des ressources est moins efficace. Par contre si deux applications veulent plus de ressources exclusives que disponible, le système dit niet à l'une d'elle (et elle "plante").
D'ailleurs je me souviens d'une discussion qui traduit un peu la différence de points de vue : pour les plus traditionalistes, le comportement du Mac qui dit "Terminal a annulé le redémarrage" était anormal car si le système décide de redémarrer, les applications n'ont rien à dire. Je préfère que l'application ait le dernier mot sur mon Mac, surtout si je n'ai pas tout sauvegardé...
@koko256
> Par contre si deux applications veulent plus de ressources exclusives que
> disponible, le système dit niet à l'une d'elle
Oui, normal. Faut-il encore que le système gère correctement le mécanisme d'exclusivité.
> (et elle "plante").
Euh, ca, non. Au lieu de planter, une bonne application indiquera une erreur à l'utilisateur avec assez d'information pour qu'il en comprenne la cause afin qu'il puisse y réagir.
Le plantage, en soit, c'est un bug.
> le comportement du Mac qui dit "Terminal a annulé le redémarrage"
> était anormal car si le système décide de redémarrer, les applications
> n'ont rien à dire. Je préfère que l'application ait le dernier mot sur
> mon Mac, surtout si je n'ai pas tout sauvegardé...
Fonctionnellement, oui.
Mais au final c'est bel et bien le système qui a le dernier mot.
Il se trouve que fonctionnellement il demande aux applications encore active leur avis, mais c'est bel et bien lui et lui seul qui décide quoi faire de la collecte de ces avis, et aucune de ces applications ayant répondu "non, stop!" ne pourraient s'opposer à ce que le système décide de passer en force parce que l'utilisateur a confirmer de vouloir passer en force.
Ne pas confondre une fonctionnalité qui "semble" donner la main aux applications avec la réalité technique. A aucun moment c'est Terminal.app qui a, toute seule comme une grande, empêché macOS de s'arrêter. C'est le système qui, conformément aux réglages de l'utilisateur, a tenu compte de sa réponse à une notification de shutdown pour l'abandonner. L'OS est bien celui qui a gardé le contrôle tout le long.
Pour une ressource matérielle tel qu'un accélérateur de codec vidéo, qui n'est que rarement partageable à plusieurs ou tout du moins sans impact majeur sur les performances, c'est au système, via les pilotes et l'api VideoToolBox, de gérer correctement l'attribution soit exclusive soit dynamique de l'accélerateur, et la responsabilité de *chaque* app de réagir correctement en fonction de cette attribution ou de son refus.
La responsabilité de chacun s'arrête à son périmètre d'intervention.
Ni Google ni FCP X ne sont responsables du code dans VideoToolBox.
Si l'usage du premier de ce code abouti à un plantage du second quand il cherche lui aussi à l'utiliser, la cause est le code de VideoToolBox *et* le code de FCP X qui plante au lieu de gérer une situation prorablement prévu par l'interface de VideoToolBox mais pas forcément prise en compte correctement par le code FCP X.
@byte_order
C'est dur de faire plus péremptoirement. Il n'y avait aucune information supplémentaire dans ce "wall of text".
J'ai mis plante entre guillemet car un application qui affiche un message d'erreur comme quoi elle ne peut pas se lancer on dit habituellement qu'elle plante même si ça n'est pas le cas au niveau purement informatique.
L'histoire du terminal était une analogie pour illustrer deux points de vue différents sur la conception d'OS et non le même cas de figure (c'était évident sauf pour vous qui prenez systématiquement votre interlocuteur pour un imbécile).
En tout cas le "bug" peut venir de Chrome qui demande trop de ressources exclusives et non du système. Le système pourrait donner la priorité à une autre application (en tuant Chrome, comme il peut forcer l'arrêt) mais ne le fait pas car c'est l'utilisateur qui doit être aux commandes et fermer Chrome lui-même (c'est d'ailleurs ce qui est fait... miracle).
@koko256
> En tout cas le "bug" peut venir de Chrome qui demande trop de ressources exclusives
> et non du système.
Comme Chrome n'affiche pas dans ce cas là de comportement qui indiquerait qu'il soit "planté", y compris sous votre définition, alors que par ailleurs c'est une autre application qui se met à dysfonctionner voir s'arrêter subitement, je vois mal par quel chemin logique on peut localiser le bug *dans* Chrome.
Il obtient l'accès à une ressource. Il s'en sert. Scandale !?
Si le système lui donne en espérant qu'il s'en servira pas trop mais ne fait rien pour éviter les abus alors qu'il sait que cela va gravement nuire à d'autres applications, le bug est dans le système qui donne et contrôle l'accès aux ressources.
C'est simple, remplacer VideoToolBox dans cette histoire par "mémoire" ou "cpu" ou "stockage persistent" ou même "écran, clavier, souris, etc", et reprenez vos réactions. Vous trouveriez normal de pointer du doigt une application A qui a obtenu et utilise la ressource obtenue parce qu'une autre application "plante" quand elle n'obtient pas la même ressource qu'elle a alors besoin ?
Et vous trouveriez normal que ce soit à l'utilisateur de faire l'arbitre sur l'accès à cette ressource à la place de l'OS ?
Retourner sur MacOS classic, où l'utilisateur pouvait allouer lui même la quantité de mémoire max *et* pré-réservée à chaque programme. Et avait encore un multitâche coopératif, sans mémoire virtuelle...
Et vous appelez la gestion des ressources par l'OS un "modèle à papa", où tout serait moins efficace !?
Etrangement, personne ne regrette ces "fonctionnalités" de nos jours.
@byte_order
"subitement, je vois mal par quel chemin logique on peut localiser le bug dans Chrome."
Ce n'est pas grave. Je ne vous en veux pas.
Moi non plus, je ne vous en veux pas !
Ouafff, ouafff, grrrr !
Et puis installer Chrome sur une station de travail pour faire du montage vidéo professionnel, comment dire, c'est que l'on aime vraiment les problèmes.
Pourquoi pas aussi Candy Crush Saga pendant que l'on y est...
@Scooby-Doo
Il "parait" qu'il y a de plus en plus de personne qui vivent de ce qu'ils postent sur leur compte Youtube. Il parait même qu'ils utilisent des logiciels de montage vidéo pour cela.
Mais bon, une tâche, un ordinateur, c'est tellement moderne comme concept.
Méchant Google ?
Gentil Google :-)
Pas mordre le pôvre Scooby-Doo !
Ouarfffff, grrr, scroumch, purée c'est qu'il mord la sale bête !
Je n'utilise pas chrome, par contre HandBrake presque quotidiennement, mais j'évite autant que possible de faire des encodages vidéos en même temps que je travaille avec FCPX. Après lecture de l'article, j'ai fais quand même un petit test par curiosité : 1h30 d'encodage avec Handbrake, en même temps qu'un montage 2 caméras + correction colorimétrique simple sur FCPX. Résultat : aucun crash, pas de ralentissement... l'encodage sur Handbrake a duré un peu plus longtemps que prévu. Je suis sur un MBP 15 de 2016 (sans problème de clavier?).
Question : le problème pourrait-il venir d'une configuration un peu "faible" ? Quoi qu'il en soit, personnellement, j'éviterai d'utiliser un navigateur web aussi gourmand en même temps que j'ai une tâche de montage en cours...
@Oliborg
J'imagine aussi que l'usage conjoint de HandBrake + FCPX est plus commun, ce qui aide à faire remonter des bugs aux développeurs. Ou Safari + FCPX (les ingénieurs bossent dans la même boite, dans ce cas là).
Par ailleurs, cela dépend aussi du codec. Tout rendu par Handbrake n'utilise pas forcément systématiquement les services de VTB...
Les Googols accusent cet article d’être anti Google, alors que les rédacteurs ne cessent de pondre des articles vantant les services de Google.
Ils n’acceptent pas la moindre critique.
@ClownWorld
Cela serait Firefox ou même Safari à la place de Chrome que j'aurais exactement la même opinion : une app qui fait planter une autre app sur un OS moderne, c'est de facto un défaut dans l'OS.
Sinon, autant défendre le retour aux OS multitâches "coopératifs" et à la gestion de la mémoire physique de manière coopérative aussi...
J'accuse pas cet article d'être anti-Google, j'accuse cet article de passer sous silence qu'un OS moderne est censé protéger les apps les unes des autres, c'est son taf principal, et que quand une app plante lorsqu'elle s'exécute en même temps qu'une autre app, c'est qu'il y a un bug dans l'OS.
Ce qui n'est pas un scandale, les bugs cela existe, en particulier dans des trucs aussi complexe qu'un système d'exploitation, mais cela ne valide pas pour autant de pointer du doigt n'importe comment.
Mieux que quitter Chrome, le virer de l'ordi !
FireFox ou Safari font bien le boulot.
Je ne vois pas quel intérêt à donner encore plus de ses données personnelles à Google.
Si vous avez Chrome, ouvrez la Console et affichez "system.log".
Vous serez surpris.
"Mieux que quitter Chrome, le virer de l'ordi !"
Ou encore mieux, carrément ne pas installer le mammouth !
Et cela évitera de devoir nettoyer tout l'OS par la suite...
Je vois beaucoup de commentaires qui accusent le système au lieu de Chrome.
Je trouve les arguments corrects.
Ce que je ne comprends pas c'est comment expliqué que les problèmes disparaissent en effaçant Chrome et en utilisant Safari.
bref vous dégagez cette bouse de Chrome si vous voulez faire de la video professionnelle sur la machine
fin du problème
fin du débat
Vous arrivez à lire dans le cerveau de Scooby-Doo à distance !
C'est de la télépathie canine avec interface homme / chien !
Admiratif de rencontrer un esprit capable de cette prouesse intellectuelle !
Pages