我正在开发一个小型库,作为一些应用程序的基础。当我要创建一个场景(2D)时,我想知道在性能、可维护性、易用性等方面,以下哪种方法看起来更有希望。
第一种解决方案有一个缺点:对于像圆形这样的原始元素(在抽签调用中不能传递矩阵),必须访问矩阵的转换值,如下所示:
private float get(int index) {
final float[] values = new float[9];
getValues(values);
return values[index];
}
public float getX() {
return get(Matrix.MTRANS_X);
}
public float getY() {
return get(Matrix.MTRANS_Y);
}因此,在每次抽签调用中,我为每个getter调用创建一个浮动数组(一个用于getX(),一个用于getY())。假设我在屏幕上有很多元素,这可能会导致内存和性能的影响。
第二种方法有“消极”思维的缺点。如果我想在100/100点绘制一个元素,我必须将画布转换为-100/-100,就像我在0/0上所画的那样。如果在此之后还原画布,结果将是在所需的100/100上绘制元素。我不确定这种消极的想法是否会对代码的可维护性和理解造成严重的影响(甚至不会因为忘记否定某件事情而开始考虑引入bug.)。
有人有什么建议应该选择哪种方式吗?
发布于 2012-10-24 18:11:17
事实上,这两种解决办法似乎都必须结合起来。
我对第二种方法的假设是完全错误的。如果我将一个元素转换为100/100,则原点将更改为100/100。当然,这也适用于画布。消极的想法完全是我的胡说八道。
合并后的结果如下:
save()保存,通过提供的方法concat(Matrix matrix),可以应用元素的矩阵。绘图将完成,画布将恢复使用restore()。这使得没有任何大的实现工作的2D场景图的实现。
发布于 2012-10-23 19:59:59
出于性能原因,使用内部矩阵方法可能会更快,因为它允许库自动加速,如果您是这样做的话。再说一遍,我不完全确定它是否会被硬件加速。
第二种方式很有趣。从长远来看,它肯定会给你更多的力量和灵活性。另外,你也许可以把这两者结合起来。
还有#3:当你说可绘制元素时,如果你使用的是Android,你可以创建一个定制的可绘制类。
我不认为有什么完美的方法
https://stackoverflow.com/questions/13012514
复制相似问题