These are chat archives for AvaloniaUI/Avalonia

9th
Feb 2017
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:15
@grokys is DefaultRenderLoop ticking from non-UI thread?
Steven Kirk
@grokys
Feb 09 2017 12:19
yeah actually i think DefaultRenderLoop still runs on UI thread at the moment
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:20
We need a way to tell the render loop
Steven Kirk
@grokys
Feb 09 2017 12:20
btw just pushed some commits to make geometry clipping work
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:20
what thread we expect
Since ImmediateRenderer will benefit from ticking on UI thread
That will reduce delay
while DeferredRenderer wants to tick on background one
On iOS you can create CADisplayLink on a both of them, I think
Steven Kirk
@grokys
Feb 09 2017 12:23
hmm yeah. or we need a Dispatcher.Invoke which just runs the method immediately if already on UI thread
but then yeah you're right
we need a way of communicating "we're using immediate rendering, run on UI thread"
but then... if you're using immediate rendering, you can just override the registered IRenderLoop
one of the main uses for immediate rendering i imagine will be e.g. game stuff
Steven Kirk
@grokys
Feb 09 2017 12:28
in that case they'll want to supply their own render loop
danwalmsley
@danwalmsley
Feb 09 2017 12:32
@grokys wrt dispatcher invoke, I sometimes use the current way it works, calling from uithread to have some things done on the next time round the loop, so if we changed its behavior could break some things for me
Maybe an invoke and invokeimmediate?
Steven Kirk
@grokys
Feb 09 2017 12:32
oh yeah, the current behavior is definitely useful
there should be both options
i think our IScheduler already does the immediate dispatch on the same thread
danwalmsley
@danwalmsley
Feb 09 2017 12:33
Or just an optional bool to activate the proposed behavior
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:34
BTW, we can't use GLKView's OpenGL context from a background thread
danwalmsley
@danwalmsley
Feb 09 2017 12:34
Though most of the time i did that it was usually a workaround for ui not updating correctly
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:34
In fact the only way to get hw-accel is to get it in draw handler
So at least composition part has to live on UI thread
The idea is that GLKView has display method
Which can trigger an immediate call to draw handler
But that can be only used from UI thread I think
And you still can't get drawing context right away
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:39
You will only receive it in callback
I see a solution with 2 render loops
one running in background and using FBO as it's output
Another running on UI thread and checking if there is a completed rendering operation from background thread
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:46
@grokys I also don't see why this whole system with layers and render-only-what-needs-to-be-rendered can't be used from ImmediateRenderer
Why do we need a separate thread for that?
Steven Kirk
@grokys
Feb 09 2017 12:49
you don't i guess
i wanted ImmediateRenderer to essentially be how we were drawing before, mainly so i can compare while i'm developing
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:50
I'll be digging into GLKit further
may be there is a proper way to offload rendering to a separate thread completely
Steven Kirk
@grokys
Feb 09 2017 12:51
cool!
for the moment i think we should just get this working on the desktop platforms, or wherever it can work without much change. then once it's tested and working there, we can make the necessary changes to get it working elsewhere
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:54
Well, it's better to know your limitations beforehand
Matthijs ter Woord
@mterwoord
Feb 09 2017 12:54
@kekekeks you need info from the main thread's event? or you just need to handle the drawing ina thread-safe manner?
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:55
@mterwoord the question is that if we can access view's OpenGL context from a separate thread or not
Android, for example, doesn't have issues with that whatsoever
Matthijs ter Woord
@mterwoord
Feb 09 2017 12:55
ok. just asking.
Nikita Tsukanov
@kekekeks
Feb 09 2017 12:55
OpenGL rendering is done on background thread by default
But if we have to render to FBO and then pass it to UI thread, there will be a performance degradation
@grokys there also should still be a way to force immediate redraw
Steven Kirk
@grokys
Feb 09 2017 12:59
yeah, we need that for e.g. window resizing
Nikita Tsukanov
@kekekeks
Feb 09 2017 14:18
Guys, I'm inclined to implement Quartz backen in ObjC and just P/Invoke that lib
Talk me out of it
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 15:04
I already have a partially working one. Whatever you decide you should start with my code.
Nikita Tsukanov
@kekekeks
Feb 09 2017 15:22
I've just asked xamarin guys
We won't be able to use their bindings for .NET Core
Since they depend on Mono runtime internals
in their objc-runtime support code
And that's wont be easy to change
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 15:50
Ok 👌. At least we can deploy the native libs easily with .net core and the relevant packages.
Nikita Tsukanov
@kekekeks
Feb 09 2017 17:17
Yep, in case of OSX that should be an issue
What I'm concerned about is compiling native binaries on AppVeyor
Since we need them for nuget
But I'm not sure about the legal status of using it
And I'm not a big fan of gathering build artifacts from multiple nodes
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 17:45
Btw vs2017 release date came out. Its releasing on Mar 7.
Steven Kirk
@grokys
Feb 09 2017 17:46
where did you read that?
:)
just happened to have copied the link already..
Steven Kirk
@grokys
Feb 09 2017 17:47
oh good, no more NDA then!
Nikita Tsukanov
@kekekeks
Feb 09 2017 20:43
You knew
So we can start moving to netstanddard
BTW, our AppVeyor account has access to VS2017 image
Steven Kirk
@grokys
Feb 09 2017 20:46
ha yeah, i've known for a little while, which is why i wasn't wanting to do the move to RC
Nikita Tsukanov
@kekekeks
Feb 09 2017 20:48
Current RC seems usable
Well, it was usable even in December
but only for small things
So, are we postponing alpha-5 till Marth the 9th or something like that?
I think it will be worth to release that last alpha as a set of NETStandard libs
So there won't be any weird hacks to make stuff compile
Steven Kirk
@grokys
Feb 09 2017 20:56
yeah probably worth waiting until we can do a .net standard release
Nikita Tsukanov
@kekekeks
Feb 09 2017 20:58
So someone could start migration somewhere around first days of March and then we'll merge it after VS release
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 20:59
Speaking of Alpha-5, can someone update our roadmap in our wiki? It seems a little out of date.
Nikita Tsukanov
@kekekeks
Feb 09 2017 20:59
We have milestones now
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 21:00
True. But a good amount of that roadmap isn't in issues yet.
Nikita Tsukanov
@kekekeks
Feb 09 2017 21:04
I'm looking at the roadmap and it still feels somewhat valid
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 21:05
There's only a few things here and there that need to be moved around.
And the links are dead now since the repo and org name changes.
Nikita Tsukanov
@kekekeks
Feb 09 2017 21:12
Nope, they aren't
github has support for redirects
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 21:13
Weird, the Mouse Transparency issue gave me a 404 when I just tried the link. Idk what happened that time.
Nikita Tsukanov
@kekekeks
Feb 09 2017 21:13
@jkoritzinsky now that I think about it, it's probably better to get a proper backend using Xamarin.Mac and then port it to custom bindings somewhere around beta2
That will allow us to know our limitations
And won't introduce any unnecessary complications during backend development
Jeremy Koritzinsky
@jkoritzinsky
Feb 09 2017 21:15
I agree. That way we can have something we know that works and then port from there. And since we have GTK3 as a fallback we shouldn't have too many issues till we get a .net core Mac native backend.
If you want to work on it you can pull down my branch and go from there. I don't have a lot of time to focus on that branch right now.