Hi,
I'm using imx8mp-var-dart board and it's Android13.
I am drawing using GLES.
(Image ,, and Lottie,, etc..)
The problem is that, like Lottie, you draw directly with Canvas' DrawPath.
It takes an incredibly long time, especially on nxp boards.
I have prepared sample code to help you understand.
When run, the flower (tulip) continues to be drawn at 30fps.
It's a very simple drawing, but it takes 400ms!!!
This is part of the example code. It takes a very long time here.
-------------------------------------------------- -------------------------------
Canvas canvas;
if (HW_DRAW) {
canvas = surface.lockHardwareCanvas();
} else {
canvas = surface.lockCanvas(null);
}
//drawStar(canvas, 1920 / 2f, 1080 / 2f, 100f, 50f, 5);
drawFlower(canvas, 1920, 1080);
//TODO: this!!
// If you unlcokCanvas after performing a lot of drawing operations such as path/line, it takes an incredibly long time for hwcanvas!!
// This problem only occurs on NXP boards!!
long unlockStartTime = System.currentTimeMillis();
surface.unlockCanvasAndPost(canvas);
long unlockEndTime = System.currentTimeMillis();
Log.w("TEST","unlock canvas diff:" + (unlockEndTime - unlockStartTime));
-------------------------------------------------- --------------------------------
It takes 400ms to unlockCanvasAndPost.
You can check it with the TEST log.
There is no problem drawing bitmaps, etc. with hw canavs.
Problems occur only when drawing with multiple paths or lines on the canvas.
What's interesting is that this log is always visible when a problem occurs.
-------------------------------------------------- --------------
02-14 11:52:52.375 7590 7624 D v_gal : gcSHADER_WriteBufferToFile: Failed to open the file /data/vendor/.opencl-cache/viv_gc_img_builtin.lib for writing
02-14 11:52:52.372 7590 7590 W RenderThread: type=1400 audit(0.0:206): avc: denied { search } for name=".opencl-cache" dev="dm-38" ino=302 scontext= u:r:system_app:s0 tcontext=u:object_r:opencl_cache_file:s0 t permissive=0
-------------------------------------------------- --------------
When there is no problem, it is not visible at all.
Giving sepolicy permission does not solve the problem.
This phenomenon only occurs on NXP boards and is not really a problem on any other Android SOC boards I have.
Please help me with this problem!
thanks.
