AVERTISSEMENT: Sortie du vertex shader 'v_gradient" à ne pas lire par le fragment shader
Quand je lance mon application dans ios 10 à l'aide de xcode 8 j'obtiens le message suivant dans la console de débogage, et par l'INTERFACE utilisateur se fige peut-on savoir pourquoi ce qui se passe
ERROR
/BuildRoot/Library/Caches/com.apple.xbs/Sources/VectorKit/VectorKit-1228.30.7.17.9/GeoGL/GeoGL/GLCoreContext.cpp
1763: InfoLog SolidRibbonShader: ERROR
/BuildRoot/Library/Caches/com.apple.xbs/Sources/VectorKit/VectorKit-1228.30.7.17.9/GeoGL/GeoGL/GLCoreContext.cpp
1764: WARNING: Output of vertex shader 'v_gradient' not read by
fragment shader
- J'ai rencontre ce problème aussi.
- êtes-vous à l'aide de mapview dans votre application
- j'ai rencontré des mêmes erreurs, j'utilise MKMapSnapshotter et MapView. J'ai des erreurs sur les deux.
- oui, je suis également en utilisant MKMapview
- Je suis également en utilisant MKMapView et obtenez cette erreur.
- ma demande gelé uniquement en mode de débogage sinon tout fonctionne bien, mais obtient toujours cet avertissement
- Je peux confirmer cela n'arrive que dans les versions de débogage. Mais certainement d'un bug qui devrait être signalé à Apple.
- J'ai un affichage de la carte dans la page. Toutefois, ce problème se produit uniquement quand j'ai un inputAccessoryView sur la VC.
Vous devez vous connecter pour publier un commentaire.
Réponse
L'une des situations où vous pourriez obtenir cet avertissement dans Xcode est lors de l'utilisation d'une application qui utilise les shaders comme le Cartes application avec un
MKMapView
. Vous verrez que la carte fonctionne comme prévu, sans que l'avertissement sur un périphérique réel avec de vrais matériel/système d'exploitation natif.Dans la carte sim de l'
SolidRibbonShader
fragment shader n'est pas en mesure de lire la sortie de lav_gradient
vertex shader probablement parce qu'il est en beta ou il pourrait y avoir une incompatibilité entre Xcode version SIM et version. Cependant, les shaders sont reconnues sur un périphérique réel.Explication
Ces shaders appartiennent à la OpenGL Pipeline de Rendu. Le Pipeline de Rendu est la séquence d'étapes OpenGL prend lors du rendu des objets.
Le pipeline de rendu responsable pour des choses telles que l'application de la texture, de la conversion des sommets à la droite système de coordonnées et afficher les caractères sur l'écran etc.
Il y a six étapes dans ce pipeline.
Enfin, une image apparaît sur l'écran de votre appareil. Ces six étapes sont appelés les OpenGL Pipeline de Rendu et toutes les données utilisées pour le rendu doit passer par là.
Qu'est ce qu'un shader?
Un shader est un programme qui vous, qui vit dans le GPU. Un shader est écrit dans un langage graphique appelé OpenGL Shading Language(GLSL).
Un shader qui prend la place de deux étapes importantes dans le Pipeline de Rendu OpenGL: Per-Vertex Traitement et Par-Fragment de Traitement scène. Il y en a un shader pour chacune de ces deux étapes.
Le but ultime de la
Vertex Shader
est de fournir à la transformation finale des sommets du maillage pour le pipeline de rendu. L'objectif de laFragment shader
est de fournir la Coloration et la Texture de données pour chaque pixel de partir pour le framebuffer.Vertex shaders
transformer les sommets d'un triangle à partir d'un modèle local de système de coordonnées à la position de l'écran.Fragment shaders
calculer la couleur d'un pixel à l'intérieur d'un triangle pixellisées sur l'écran.Séparé Shader Objets d'accélérer la Compilation et la Liaison
De nombreux OpenGL ES aux applications d'utiliser plusieurs vertex et fragment shaders, et il est souvent utile de réutiliser le même fragment shader avec différents vertex shaders ou vice versa. Parce que le coeur OpenGL ES spécification exige une vertex et fragment shader pour être reliés à un seul programme de shaders, le mélange et l'appariement des shaders résultats dans un grand nombre de programmes, l'accroissement total de shader compiler et lier de temps lors de l'initialisation de votre application.
Mise à jour: le problème semble avoir disparu maintenant sur Xcode9/iOS11.
Tout d'abord, le gel problème se produit uniquement lorsque vous exécutez à partir Xcode 8 et uniquement sur iOS 10 (actuellement 10.0.2), que ce soit en mode debug ou release. MKMapView mais semble très bien lorsque l'application est distribuée via l'App Store ou le 3e partie ad hoc sur les systèmes de distribution. Les mises en garde que vous voyez peut ou peut ne pas être liée au problème, je ne sais pas.
Ce que j'ai trouvé, c'est que le code malveillant est en MKMapView du destructeur, et il n'a pas d'importance ce que vous faites avec la vue de la carte de l'objet ou de la façon dont vous le configurer, c'est à dire simplement appeler
n'importe où dans votre code freeze de l'application. Le thread principal se bloque sur un sémaphore et il n'est pas clair pourquoi.
Une des choses que j'ai essayé était de détruire la vue de la carte de l'objet dans un thread séparé, mais cela n'a pas aidé. Finalement, j'ai décidé de conserver mon les objets de la carte, au moins dans les versions DEBUG.
NOTE: c'est vraiment un sh*tty solution de contournement, mais au moins il va vous aider à déboguer votre application sans gel. En conservant ces objets signifie que votre utilisation de la mémoire va croître d'environ 45-50 MO à chaque fois que vous créez une vue contrôleur avec une carte.
Donc, disons que si vous avez une propriété
mapView
, alors vous pouvez le faire dans votre vue du contrôleur de dealloc:#if DEBUG
, j'utiliseif(AmIBeingDebugged())
.