These are chat archives for AvaloniaUI/Avalonia

10th
Feb 2017
Nikita Tsukanov
@kekekeks
Feb 10 2017 12:24
@grokys are we going to deprecate Cairo backend?
It is not maintained and doesn't work on .NET Core anyway
Steven Kirk
@grokys
Feb 10 2017 13:16
does skia work fine on linux now?
Nikita Tsukanov
@kekekeks
Feb 10 2017 13:18
I haven't encountered any issues so far
You still need a native library though
I'm asking because it seems that cairo lacks the ability to load font from file
There is some hacks with pango/fontconfig, but I'm not sure that it will work properly
Also, regarding fonts
Do we need to use that system with ISmthImpl with fonts?
I'd rather make them abstract classes
Oh, nvm, we probably still want to provide constructors
Steven Kirk
@grokys
Feb 10 2017 13:31
i'd like to remove cairo, but my only concern is the native library stuff - it might be too high a hurdle for some people who just want to try us out. cairo at least works immediately on linux.
Matthijs ter Woord
@mterwoord
Feb 10 2017 13:57
@kekekeks you mean its still not a fully managed .net dll?
Nikita Tsukanov
@kekekeks
Feb 10 2017 14:05
it won't be
skia is a C++ library
Matthijs ter Woord
@mterwoord
Feb 10 2017 14:26
ok, so you were just stating it to be sure..
thought you were mentioning it as a "too bad" kind of note..
Nikita Tsukanov
@kekekeks
Feb 10 2017 14:28
Currently we have an issue with SkiaSharp package lacking a prebuilt libSkiaSharp.so
Nikita Tsukanov
@kekekeks
Feb 10 2017 15:34
@danwalmsley I've managed to build libSkiaSharp.so using Holy Build Box
7MB
And portable
At least it works on my ubuntu
Nikita Tsukanov
@kekekeks
Feb 10 2017 15:46
@grokys if we distribute that library as part of our nuget package, it should work out of the box
Well, not exactly out of the box, still need to somehow tell mono to load it
Steven Kirk
@grokys
Feb 10 2017 16:14
will that work on iOS too?
Nikita Tsukanov
@kekekeks
Feb 10 2017 16:14
Ehm
SkiaSharp already provides prebuild native library for iOS
And for OS X
And for Windows
And for Android
And for UWP
Basically for everything but linux
Because of that legion of linux distributions clusterfuck
I've managed to produce a library that will work on most of actually used ones
Steven Kirk
@grokys
Feb 10 2017 16:23
ok great
Nikita Tsukanov
@kekekeks
Feb 10 2017 16:29
I hope that xamarin will use my docker image to produce builds
for now I've opened a PR for using static version of libfreetype
mono/SkiaSharp#238
Steven Kirk
@grokys
Feb 10 2017 17:37
so we need to make sure the renderer has stopped before we close the window, as the window can close at any time during the render cycle currently, causing access violations etc
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:37
That's why you need a separate "composition" step, I think
Steven Kirk
@grokys
Feb 10 2017 17:38
i was thinking to do that we could implement CanClose and if true is returned, wait for the current render to stop, and dispose the renderer
would that not work for mobile?
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:38
On mobile you don't exactly have "window render target"
And it seems that you aren't supposed to access on-screen surface at arbitrary point of time
only from callbacks
Steven Kirk
@grokys
Feb 10 2017 17:41
are any of those callbacks in the form of something resembling a render loop?
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:42
They are on per-view basis
Steven Kirk
@grokys
Feb 10 2017 17:44
i know you spoke about this before btw, i wasn't ignoring you, i just needed to get to a point where things kinda worked on desktop before i had the bandwidth to think about them!
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:45
The point is that you can't render to a "window" there
I think this guy have encountered the same problem on Android
In case of iOS there shouldn't be any issues, since CAEAGLLayer instances can be managed by user code
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:51
I think that basically means that we should render to offscreen surface and then post it to UI thread
Steven Kirk
@grokys
Feb 10 2017 17:52
ok
so we can do that for android and for other platforms, make sure the renderer has stopped before allowing the OS to destroy the window or whatever?
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:53
Or somehow update on-screen surface from background thread and handle error there
On android you don't have any control
you are getting surfacedestroyed callback even if your view goes offscreen for whatever reason
Steven Kirk
@grokys
Feb 10 2017 17:54
if we can handle the error that might be an option
Nikita Tsukanov
@kekekeks
Feb 10 2017 17:55
The problem is that skia will probably silently fail and won't tell us what happened
I guess we should render to FBO
and call eglCreateWindowSurface only for "swapping buffers"
Steven Kirk
@grokys
Feb 10 2017 18:04
any idea what chrome does here?
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:05
Nope
Well, I don't think that intermediate surface will introduce any overhead
Just call eglCreatePbufferSurface and use it for rendering
BTW, CanClose isn't a silver bullet
It should be platform-specific
On windows it should be safe to wait for render thread from Closed handler
Since it's being called from WM_DESTROY handler
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:10
And at that time window still exists
It's already removed from screen, but HWND is still valid
I suggest to add public CancellationToken Closed {get;} to window's PlatformHandle
So rendering subsystem will be able to subscribe to said handle
And postpone window destruction until current DrawingContext is released
In case of ILockedFramebuffer render target its assumed to be alive until disposal
And I'm planning to introduce OpenGLContext "platform surface" that will be responsible for lifetime management
So there is no need to touch xplat code
Steven Kirk
@grokys
Feb 10 2017 18:14
hmm it doesn't seem to be safe to do it there
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:15
Well, it's only Direct2D1 that wants HWND, you know
Skia doesn't care about target surface, as long as it's provided with a framebuffer or OpenGL context to render to
Steven Kirk
@grokys
Feb 10 2017 18:15
hmm ok
that didn't seem to be the case, i need to re-investigate
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:16
We were keeping our platform-specific code in Avalonia.Skia library
That was a vestige from native renderer library times
But skia itself doesn't care
And doesn't provide us with on-screen render targets
Steven Kirk
@grokys
Feb 10 2017 18:21
ok, i need to look into that again - i did a thing where we wait for the current render to finish in Dispose but it didn't seem to work
maybe i didn't do it properly, it was late ;)
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:24
You probably need to re-introduce IPlatformWindowHandleSurface interface in this case
Since now it will have 2 members
IntPtr Handle and CancellationToken Closed
Steven Kirk
@grokys
Feb 10 2017 18:30
i was just going to do a wait on a lock in IRenderer.Dispose
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:33
Probably a bad idea
It doesn't solve the issue when old surface is being replaced by another one
Steven Kirk
@grokys
Feb 10 2017 18:34
on android?
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:34
At least on android, yes
So it's not a generic solution
Steven Kirk
@grokys
Feb 10 2017 18:34
ok, so i thought on android we'd compose on main thread?
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:35
You see, stability should be guaranteed by platform-specific code
And not somewhat hacked around in xplat-one
Steven Kirk
@grokys
Feb 10 2017 18:35
so we need to check a cancellation token before each draw?
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:35
Wait a moment, please, I'm writing implementation right now
Steven Kirk
@grokys
Feb 10 2017 18:51
i'm just trying to work out why controlcatalog with the deferred renderer takes twice as much memory as the immediate renderer, even though we seem to have allocated less (??) managed memory
Matthijs ter Woord
@mterwoord
Feb 10 2017 18:51
skia buffers which are thought to be used later?
Steven Kirk
@grokys
Feb 10 2017 18:52
this is with D2D
just tried skia, and it uses less memory somehow!
that's a good sign, although I have no idea how it could be possible
Nikita Tsukanov
@kekekeks
Feb 10 2017 18:54
Direct2D uses half-retained mode, told ya
I'm checking that I haven't broken anything
Will push code soon
Steven Kirk
@grokys
Feb 10 2017 18:55
thanks! i need to go out soon, but will check tomorrow
Nikita Tsukanov
@kekekeks
Feb 10 2017 19:00
AvaloniaUI/Avalonia#888
Somewhat like that
Steven Kirk
@grokys
Feb 10 2017 19:11
ok, will take a look, thanks a lot!
it's easier to explain in code :)
Nikita Tsukanov
@kekekeks
Feb 10 2017 20:56
@grokys I was thinking about visualizer (aka designer). Right now I have to do some voodoo magic with window implementation to get it working. Could we make it possible to have TopLevel as a child control?
Nikita Tsukanov
@kekekeks
Feb 10 2017 21:11
It would also allow to create some kind of window manager
The previous attempt failed mainly because of the amount of said voodoo magic to get it working
Steven Kirk
@grokys
Feb 10 2017 23:09
yeah, we could do that i think
we might have to shuffle stuff around a bit
This is still relevant
Steven Kirk
@grokys
Feb 10 2017 23:22
yep, that sounds like a plan