Sampler

3 月，跳不动了？>>> 采样：利用纹理坐标取得纹理颜色 采样器： 片段着色器也应该能访问纹理对象，但是怎样能把纹理对象传给片段着色器呢？GLSL有一个供纹理对象使用的内建数据类型，叫做采样器(Sampler)，它以纹理类型作为后缀，比如 sampler1D 、 sampler3D ，或 sampler2D 。可以简单声明一个 uniform sampler2D 把一个纹理添加到片段着色器中，稍后把纹理赋值给这个uniform。 OpenGL至少保证有16个纹理单元供你使用，也就是说你可以激活从GL_TEXTURE0到GL_TEXTRUE15。它们都是按顺序定义的，所以也可以通过GL_TEXTURE0 + 8的方式获得GL_TEXTURE8，这在当我们需要循环一些纹理单元的时候会很有用。 #version 330 core out vec4 FragColor; in vec3 ourColor; in vec2 TexCoord; uniform float mixValue; // 采样器：解决了如何将纹理对象传给片段着色器 //纹理单元· uniform sampler2D texture1; //这个片段着色器的输出就是纹理的（插值）纹理坐标上的(过滤后的)颜色。 void main() { FragColor = texture(texture1, TexCoord) *

作者 | 孙健波（天元） 阿里巴巴技术专家 导读 ： go modules 是 golang 1.11 新加的特性。如今 1.13 都已经发布了第 7 个小版本了，几乎所有大项目均已开始使用，这自然也包括 Kubernetes 生态中的众多项目。笔者在开发 OAM 相关项目的时候，却发现 modules 的各项功能看似简单，却并没有那么好用，于是便想给大家分享一下使用心得，希望大家也能在最短时间内学会 modules 的使用，避免踩坑。 modules 是什么？ 简单说就是包管理，Golang 的包管理素来以混乱著称，以前是依赖 $GOPATH ，只要你的代码放在指定路径下就好了，完全没有“包管理”的概念。被社区吐槽了很久以后开始搞 vendor 机制，简单来说就是代码不光是可以放到指定路径，还可以放在项目自身路径的 vendor 文件夹。这个解决的问题是：你引用的代码包上游变更不会直接影响你的项目，这显然是开始关心“包版本”了。遗憾的是依旧没有解决包管理的问题，比如不同的包依赖了同一个包的不同版本怎么办？版本间代码冲突怎么办？ vendor 机制并没有解决，于是围绕 vendor/ 社区就出了几十个包管理工具，一时间百花齐放、百家争鸣、各有所长，导致 golang 的包管理生态变得有些混乱。对这段历史感兴趣的可以阅读下笔者曾经写的文章 《Go 包管理的前世今生》 。 更有意思的是

NanoVG 优化笔记 nanovg 正如其名称所示的那样，是一个非常小巧的矢量绘图函数库。相比cairo和skia的数十万行代码，nanovg不足5000行的C语言代码，称为nano也是名副其实了。nanovg的设计、接口和代码质量都堪称典范，唯一美中不足的就是性能不太理想。特别是在Android的低端机型和大屏幕的机型上，一个简单的界面每秒只能画十几帧。最近我把 AWTK 移植到Android上时，就碰到了这个尴尬的问题。 经过优化之后， AWTK 在低端机型上，整体渲染性能有了3到5倍的提升。这里做个笔记，供有需要的朋友参考。 nanovg的性能瓶颈在于片段着色器（fragment shader），片段着色器可以认为是为GPU提供的一个回调函数，该回调函数在处理每个像素时被调用，在每一帧绘制时都会执行数百万次，可见该函数的对性能的影响是很大的。 我们先看看nanovg的片段着色器（fragment shader）代码： static const char* fillFragShader = "#ifdef GL_ES\n" "#if defined(GL_FRAGMENT_PRECISION_HIGH) || defined(NANOVG_GL3)\n" " precision highp float;\n" "#else\n" " precision mediump