textarea组件的bindlinechange方法返回数据不准确。 第1行回车前 lineCount = 1。 第1行回车后 lineCount = 2。 第2行回车后 lineCount = 3。 第3行回车后 lineCount = 4。 第4行回车后 lineCount = 5。 第5行回车后 bindlinechange 未触发。 第6行回车后 lineCount = 6 （正常应该等于7）。 [图片] [图片] [图片] [图片] [图片] [图片] [图片] 相关问题： 组件textarea中的行数监听函数:bindlinechange,对6行的监听失效https://developers.weixin.qq.com/community/develop/doc/00062a0b6fc9904b5fcdea21251800?highline=textarea%E7%BB%84%E4%BB%B6%E7%9A%84bindlinechange%E6%96%B9%E6%B3%95%E8%BF%94%E5%9B%9E%E6%95%B0%E6%8D%AE%E4%B8%8D%E5%87%86%E7%A1%AE%E9%97%AE%E9%A2%98 textarea，bindlinechange监听lineCount与实际不对？https://developers.weixin.qq.com/community/develop/doc/000426aabd8870b64f3cca5615c000?_at=1695195359513

我在小程序里用image标签引入本地GIF动画，但是小程序加载后GIF就动一下就不动，请问各位大神怎么解决呢？

小程序  camera 拍摄页面目前能够实现手势缩放实现放大缩小， 不能满当前业务需求， 请问小程序是否支持，代码控制，拍摄页面焦距调整？ 或者是否有计划后续提供 camera相机拍摄页面 ，代码控制变焦功能？

配置不同的 frame-size 和 resolution 分别取 onCameraFrame 回调中的帧数据和 takephoto 的 imageInfo 得到下表 留空为未配置改属性, 理论上要 fallback 到默认 medium, 结果看来并不全是. 数据来自真机预览, iphone se2 [图片]

[图片] 如上图，我把情况录制成gif，测试使用最基础的微信官方提供的组件测试体验小程序，使用camera组件的时候不停的在对焦。同样，在不同的代码环境下，以及实际被拍摄的多种光线远近等场景都有此问题。 目前测试设备 iPad6 ios13.3.1 iPod touch7 ios13.3 手边没有其他ios设备，所以只能用这两种设备测试，都发现同样的问题，不知道是只出现在这两种设备上还是普遍存在。

[图片]

为什么camera通过CameraFrameListener拿到的实时帧数据无法通过canvas的drawImage绘制到canvas呢？是需要转换数据格式吗？也不报错也不显示图片，和我通过本地图片绘制的效果一样，都绘制不出来[图片]

使用 canvasContext.createImageData 创建一个 ImageData对象，并对 ImageData.data 进行修改后，使用 canvasContext.putImageData 进行绘制，无法正常绘制。 同时： 使用 canvasContext.getImageData 拿到的 imageData，修改 ImageData.data 后，使用canvasContext.putImageData 进行绘制，修改的内容无法绘制。 目前 微信8.0.37 版本的安卓客户端存在问题，之前的 8.0.35 正常。 测试机型： 三星 s22 + 三星 s10+

1、CameraContext.startRecord时长上限调整 2、小程序的camera组件增加自拍摄像头非镜像模式

onCameraFrame接口是个很有意思也很强大的接口，在微信小程序还没有正式的宣告AR相关能力时我已经让团队基于此功能做了些尝试了。但是在使用过程中还是有诸多不便。所以谈谈我的一点想法和小建议。 这个接口的推出，我相信产品团队是出于目前诸多的AR/视频需求而开发出来的，但是从这两个场景来看这个接口直接用起来不太方便： 采样频率不可控，目前貌似是30FPS。但是这30FPS每帧都把数据扔出来的话，直接在这个事件中接到数据然后去做些相关的业务逻辑。。。。。。根本处理不过来啊。实际的应用场景我相信大家都需要降低频率来处理数据，像我就是先写个环形缓冲区，然后再按照我实际的业务逻辑测试好速度跳帧把数据插入到环形缓冲区。最后随时需要取数据的时候，去环形缓冲区里面拿。所以，从这个角度来说，我希望这个接口提供以下两个功能以便使用起来更加灵活： 能够提供相关的参数配置使得能够按照预先设定的频率输出数据 能够提供一个接口在调用请求的时候再返回最新的当前帧数据 onCameraFrame给出的是RGBA的数据，这玩意儿数据量太大用起来也不方便，尤其是要把数据再传回服务器端处理的或者需要做些裁剪缩放的动作就呵呵了。。。别说用Canvas，用那玩意儿的性能会活活拖死你。所以建议提供以下相关接口功能以便使用起来更加灵活： 对于onCameraFrame的数据，能够有参数配置使得得到jpg或者png的数据 提供一些原生功能对于得到的图像数据进行缩放、裁剪 当然，并不是说onCameraFrame现在的功能不可用。。。。用倒是可以用。。。我们做的一个用摄像头获取数据然后回传后台服务器进行分析判断的测试小程序，如果简单自行小心翼翼的跳帧然后再放到canvas里进行裁剪缩放最后传输到服务器。。。这时间简直是无法忍受的（若干秒） 后来我们加入环形缓冲区，自己用JS来进行图像的压缩裁剪什么的再传输，才成功的把整体处理时间压缩到300~400ms。 所以，我相信如果官方能够提供原生的采样速率控制或者按需请求数据，以及原生的图像缩放裁剪功能。那么对于AR/即时视频处理类的小程序将会得到速度上质的飞跃。 -------------------------------9月5日  追加------------------------- 随便搜一下onCameraFrame关键字就能找到我这里提到的几个同类问题贴： https://developers.weixin.qq.com/community/develop/doc/00004c1441c30840dce8b4d7956000?highLine=onCameraFrame  （频率相关） https://developers.weixin.qq.com/community/develop/doc/0000ce49770450ded3e88522e56000?highLine=onCameraFrame （格式相关） https://developers.weixin.qq.com/community/develop/doc/000eeab7238bc8cba6f8840045bc00?highLine=onCameraFrame （真机无法调试onCameraFrame，我猜测也是频率过高造成，当然，仅仅只是猜测） https://developers.weixin.qq.com/community/develop/doc/0008229fccc948215bc8a8bba56800?highLine=onCameraFrame （8月9日 Keep的回复其实也是格式的问题） https://developers.weixin.qq.com/community/develop/doc/00062e5cc14b08e3750982bd457800?highLine=onCameraFrame （频率相关） https://developers.weixin.qq.com/community/develop/doc/00026e57b08e70d06519a7af656c00?highLine=onCameraFrame （图像数据的裁剪） https://developers.weixin.qq.com/community/develop/doc/000a6646b4cce8acd2981b4855f400?highLine=onCameraFrame （格式相关） https://developers.weixin.qq.com/community/develop/doc/00084ed934c730d6b8191124151400?highLine=onCameraFrame （频率相关）