我有一个运行Android 4.2.2的ASUS Nexus 7,运行以下代码时,我的应用程序在sk_malloc_flags中生成了SIGSEGV:
static Picture createDrawing() {
Path firstPath = new Path();
firstPath.moveTo(3058, 12365);
firstPath.lineTo(8499, 3038);
firstPath.lineTo(9494, 3619);
firstPath.lineTo(4053, 12946);
firstPath.close();
Path fourthPath = new Path();
fourthPath.moveTo(3065, 12332);
fourthPath.lineTo(4053, 12926);
fourthPath.lineTo(9615, 3669);
fourthPath.lineTo(8628, 3075);
fourthPath.close();
Picture picture = new Picture();
Canvas canvas = picture.beginRecording(12240, 15840);
canvas.clipPath(firstPath);
canvas.clipPath(fourthPath); << SIGSEGV occurs here
picture.endRecording();
return picture;
}
SIGSEGV报告如下:
I/DEBUG ( 124): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG ( 124): r0 00000027 r1 deadbaad r2 4017f258 r3 00000000
I/DEBUG ( 124): r4 00000000 r5 bed72434 r6 bed72508 r7 1be773bc
I/DEBUG ( 124): r8 1be730f9 r9 000042c3 sl 00000001 fp 67185010
I/DEBUG ( 124): ip 40443f3c sp bed72430 lr 401522f9 pc 4014e992 cpsr 60000030
...
I/DEBUG ( 124): backtrace:
I/DEBUG ( 124): #00 pc 0001a992 /system/lib/libc.so
I/DEBUG ( 124): #01 pc 00018070 /system/lib/libc.so (abort+4)
I/DEBUG ( 124): #02 pc 000be4b4 /system/lib/libskia.so (sk_malloc_flags(unsigned int, unsigned int)+28)
I/DEBUG ( 124): #03 pc 0008afc0 /system/lib/libskia.so (SkRegion::op(SkRegion const&, SkRegion const&, SkRegion::Op)+1716)
I/DEBUG ( 124): #04 pc 00089448 /system/lib/libskia.so (SkRasterClip::op(SkRasterClip const&, SkRegion::Op)+128)
我显然已将代码简化为上面显示的代码,整个应用程序根据一些输入数据使用转换等来生成值。对于在一般情况下不实现我自己的剪裁代码的情况下,他们是否有任何解决方法的建议?
最佳答案
对于clipPath
处理来说,这似乎是个不幸的案例。
canvas.clipPath(fourthPath);
会导致与先前的
firstPath
合并,但是由于这些形状很复杂(非矩形),系统会尝试将其绘制为scanlines
并随后进行合并。要进行合并,它需要分配一些内存,但是as you can see in SkRegion.cpp则需要heuristic worst case
。static int compute_worst_case_count(int a_count, int b_count) {
int a_intervals = count_to_intervals(a_count);
int b_intervals = count_to_intervals(b_count);
// Our heuristic worst case is ai * (bi + 1) + bi * (ai + 1)
int intervals = 2 * a_intervals * b_intervals + a_intervals + b_intervals;
// convert back to number of RunType values
return intervals_to_count(intervals);
}
对于您的路径,此
worst_case_count
接近2GB,并且由于没有从malloc
获得那么大的内存而导致中止。我看不到使用不同参数的任何方法。避免合并
clipPath
的任何事情都必须有所帮助,例如使用Region.Op.REPLACE
调用clipPath。 Region.Op.INTERSECT
也应该失败。我将集中精力避免在复杂路径之上使用复杂路径调用clipPath。
如果适合您的用例,则可以使用相同的
Path
对象设置canvas.clipPath()
。例如:Picture picture = new Picture();
Canvas canvas = picture.beginRecording(12240, 15840);
Path path = new Path();
path.moveTo(3058, 12365);
path.lineTo(8499, 3038);
path.lineTo(9494, 3619);
path.lineTo(4053, 12946);
path.close();
canvas.clipPath(path);
// do stuff with canvas
path.moveTo(3065, 12332);
path.lineTo(4053, 12926);
path.lineTo(9615, 3669);
path.lineTo(8628, 3075);
path.close();
canvas.clipPath(path, Region.Op.REPLACE);
// do more stuff with canvas
picture.endRecording();
return picture;
由于
path
包含以前的工程图,因此您可以继续对其进行更新。如果这不适用于您的情况,则需要使这些数字更小或将复杂的区域划分为较小的区域,以避免worst case heuristic
变得太大。