Open JB-Dmitry opened 1 month ago
The problem seems to be in Skia, not in Skiko's bindings. Here's the 'fiddle' that reproduces the problem: https://fiddle.skia.org/c/831a2f73004d056f1a422e5d3b053e23 And its code, for reference:
void draw(SkCanvas* canvas) {
SkPictureRecorder recorder;
SkCanvas* pictureCanvas = recorder.beginRecording({-1e9, -1e9, 1e9, 1e9});
SkRect r = SkRect::MakeWH(15, 15);
pictureCanvas->clipRect(r);
SkPaint p;
p.setColor(SK_ColorRED);
pictureCanvas->drawRect(r, p);
sk_sp<SkPicture> picture = recorder.finishRecordingAsPicture();
SkSerialProcs sProcs;
sk_sp<SkData> readableData = picture->serialize();
sk_sp<SkPicture> restored = SkPicture::MakeFromData(readableData->data(), readableData->size());
restored->playback(canvas);
}
Reproducer:
Expected result: both
direct.png
andreconstructed.png
image files have a red square on white background. Actual result:reconstructed.png
image file doesn't contain the red square.Reproduced on macOS 14.5 (M2 Max) for Skiko (Kotlin/JVM) versions 0.8.4 and 0.8.10.
Note, that increasing the
SQUARE_SIZE
value up to33
or more makes the red rectangle appear inreconstructed.png
.The problem is probably related to the cull rect, used for picture recording, being too large, so that a numerical overflow is happening somewhere in the serialization/deserialization code. Pictures with such a big cull rect are actually used in Compose code (to cache the intermediate rendering results, AFAIU), and the problem was initially observed in relation to Compose code. Here's the corresponding reproducer:
It's expected to see '0' rendered in both images, but it's absent in
reconstructed.png
. The problem was reproduced with Compose Desktop version 1.6.11.