因为对这个改动的好处不明白，我就说说这样设计蛋疼的缺陷：
3.x版本的shader因为引擎的顶点着色器默认有两种，使得shader的使用极端困难，因为有这么两个严重的问题：1.所有片段着色器效果，需要分别和这两种顶点着色器匹配 2.设置shader还需要关心所有的node到底用的是哪个顶点着色器，尤其是递归设置的时候，这个问题尤其严重，比如我需要将一个节点子树全部设置成高亮，现在简直难玩，spine动画和ProgressTimer属于MVP，Sprite又是NO_MVP 
我是来支持楼主吐槽的
mvp 就是把m，v，p三个矩阵相乘的值都传进shader， no_mvp就是只传p矩阵进shader， 这么做当然是为了优化效率， 毕竟cpu资源非常有限，让GPU来做这运算就快很多了。
如果只是效率优化，我觉得这种事情是毫无意义（因为并不会为效率带来质量的提升，这点效率微乎其微），你觉得你是喜欢运行速度飞快的砖头手机（只有一个开机动画和关机动画，他们播放的非常流畅）呢，还是一个速度一般的智能手机？
我觉得应用层的使用方便，统一 是优先于效率的，这几天依然处处碰壁：因为我没法直接用一组按钮高亮shdaer效果实现所有的按钮。。很苦恼，当然我可以在业务层解决这个，只是想反馈这种业务层的巨大麻烦其实还是归于引擎层的一些设计问题，希望引擎能越来越好。
遇到越来越多的问题，真心好烦：比如一个按钮组，需要点击呈现高亮效果，本来可以很轻松的内部递归，把child都设成同一个shader，现在只能呵呵了
2d用 nomvp
3d用mvp
其他别管
这个不行啊，像Sprite是nomvp Label又是mvp
用mvp还是nomvp跟渲染用的哪种Command有关，详细可看Renderer.cpp的渲染
-
Renderer::processRenderCommand方法中，TRIANGLES_COMMAND调用fillVerticesAndIndices方法，内部
调用 modelView.transformPoint，相当于预先乘了mv，所以shader里面就不用再乘MV了。Sprite用的就是TrianglesCommand
-
RenderCommand::Type::QUAD_COMMAND方法调用的是fillQuads方法，而fillQuads内部也同样做了mv变换
Label用的CustomCommand，所以要mvp
了解，但是本质原因就是 因为他们的顶点差异，导致不能统一做shader片段效果，比如对一个按钮高亮：需要高亮sprite以及按钮上的label
不过好在3.8.1 label终于也使用了nomvp 这种统一还是很赞的
mark一下