We have investigated this here and noticed the following registration in one of the Skia units:
TPicture.RegisterFileFormat('svg', 'Scalable Vector Graphics', TSkSvgGraphic);
Which basically registers TSkSvgGraphic as a class for handling SVG file formats and streams.
This conflicts with our own TPicture registration mechanism:
TPicture.RegisterFileFormat('SVG', 'Scalable Vector Graphics (FNC)', TTMSFNCSVGBitmap);
so depending on the way the packages are loaded, either TTMSFNCSVGBitmap or TSkSvgGraphic is registered. At designtime, this means that TSkSvgGraphic is being used as a class for our FNC components. This is no problem at first, but I noticed that the CanLoadFromStream mechanism is actually changing the Position pointer of the stream, when being loaded. So this code:
{$IF CompilerVersion >= 32}
class function TSkGraphic.CanLoadFromStream(AStream: TStream): Boolean;
const
SupportedFormats = [TSkEncodedImageFormat.WEBP, TSkEncodedImageFormat.WBMP, TSkEncodedImageFormat.DNG];
var
LCodec: ISkCodec;
begin
LCodec := TSkCodec.MakeFromStream(AStream);
Result := Assigned(LCodec) and (LCodec.EncodedImageFormat in SupportedFormats);
end;
{$ENDIF}
Is checking if the stream can be loaded, but it doesn't reset the position, which then means the stream is corrupted. Next, our own checking is applied, and it doesn't find a valid stream anymore which is the reason why it gives an access violation.
I would expect to at least reset back the position of the stream:
{$IF CompilerVersion >= 32}
class function TSkGraphic.CanLoadFromStream(AStream: TStream): Boolean;
const
SupportedFormats = [TSkEncodedImageFormat.WEBP, TSkEncodedImageFormat.WBMP, TSkEncodedImageFormat.DNG];
var
LCodec: ISkCodec;
p: Int64;
begin
p := AStream.Position;
try
LCodec := TSkCodec.MakeFromStream(AStream);
Result := Assigned(LCodec) and (LCodec.EncodedImageFormat in SupportedFormats);
finally
AStream.Position := p;
end;
end;
{$ENDIF}
So this code needs to be fixed at their side, I've created an issue at github