Acknowledged
over 1 year ago

setMatrix bug?

Had some affinetransforms which worked well in sim but not on my FR265 device (on-device log file reports ciq 4.2.4).

Wittled down to a test case which works in sim but not on device (bitmap not showing up how it should):

translateMatrix.initialize();
translateMatrix.setMatrix([
    1.0, 0.0, 0.0,
    0.0, 1.0, 0.0]);
dc.drawBitmap2(200, 200, myPngBitmap, {
  :transform => translateMatrix,
  :filterMode => Graphics.FILTER_MODE_BILINEAR
});

AFAIK it should be equal to the following code, which does work as expected on-device:

translateMatrix.initialize();
translateMatrix.setToTranslation(0.0, 0.0);
dc.drawBitmap2(200, 200, myPngBitmap, {
  :transform => translateMatrix,
  :filterMode => Graphics.FILTER_MODE_BILINEAR
});

I've had to change my real code from doing multiple operations in setMatrix/concatenate to using separate translate/scale/rotate operations.

Parents
  • I totally understand. Our documentation isn't the best, but object initializers should be treated like a constructor in C++ or Java.

    You're not the first person to do this. I just want to discourage it so we don't break your application in cases where initialize makes assumptions about the object state (we could easily assume that the object is not yet initialized when initialize is called and leak a resource).

    The compiler doesn't currently prevent it, but this is probably something we should do.

Comment
  • I totally understand. Our documentation isn't the best, but object initializers should be treated like a constructor in C++ or Java.

    You're not the first person to do this. I just want to discourage it so we don't break your application in cases where initialize makes assumptions about the object state (we could easily assume that the object is not yet initialized when initialize is called and leak a resource).

    The compiler doesn't currently prevent it, but this is probably something we should do.

Children
No Data