Indeed, this is an issue of the tooltip/IO box only. They assume the SKImage is immutable and only update if they get a new SKImage. In this case the texture stays the same though, therefor the SKImage returned is also the same. Maybe there’s a way to build a “new” SKImage around the same texture all the time? But that could also be misleading in other cases. Not entirely sure how to address this to be honest.
@Elias Maybe we can add some sort of Force pin in meantime:
var image = texture.Tags.Get(SKImageView);
if (image is null || force)
{
...
}
Also a problem that I can’t access D3D11Utils from VL.Skia.Egl if I want to override or extract, I can do this only in StandardLibs witch is not very convenient.
My latest attempt was to directly plug texture to avalonia, maybe it would be more direct way… Something like do TextureToImage inside avalonia control, but need access to D3D11Utils
Making D3D11Utils public is not really something we want to do. It somewhat locks us in / we can no longer modify it freely. Can you maybe provide a bigger picture about what you’re trying to do?
Yes, I understand the consequences, but this kind of things make advanced stuff possible, I mean, I’m not expecting this to be “rock solid”, and I’m aware that it may break in future, however I don’t want to pollute repo with 10 millions deps I need to add this thing or some kind of reflection code that would still make me able to use it… I mean maybe some ExperimentalAttribute or UnstableApi that shows a warning would be sufficient…