@galvesribeiro I am here now, just read through the discussion
yeah
just curious if you had the console problem in your engine
I mean, when you open the game have you able to supporess the console to be open?
@danwalmsley I'm not super familiar with System.Composition, but it should be unchanged from the Microsoft.Composition nuget package we used to ship
@danwalmsley We also are supporting "MEF1" (the regular .NET Framework component), but only in .NET Core / .NET Standard 2.0
The console window thing is very problematic
humm
In my game editor, when publishing a standalone version of my game, I have a step that changes the subsystem link of the executable.
I saw that
but it only work on windows
Yes, exactly
and it is kinda hack :)
I filed an issue about this a long time ago here: dotnet/core-setup#196, but there is not a lot of interest from the rest of my team
Any extra voices in there would help show the importance of it
I saw tht too
the point is, we are already using the underlying OS windowing system
the host is just to start the clr
Right
we would just need somehow to skip that terminal thing
Unfortunately the "host" is also the thing that runs SDK commands, so we need the console for that
otherwise, we would need to create our own host which is totally undesirable
:(
And we also need a console if the program being hosted uses console output
yeah, at development it is useful, but publishing it isnt
In my opinion the right thing to do is unconditionally link
dotnet.exe against the Windows subsystem, and then conditionally create a console window based on some metadata in the project
in the project / published exe
yep
one question
instead of use dotnet as the host
is there a way to when
dotnet publishto create the host for us? basically a self-contained app
I heard about it in the past
but noone looks to use it
Yes, it's quite easy
like embedding the framework etc
how
?
Yeah, it's very simple
If you are using the new csproj stuff
I am
You list
<RuntimeIdentifiers>win7-x64;OTHER_STUFF</RuntimeIdentifiers> in your project
humm
that would be good for containers :)
And then you pass
/p:RuntimeIdentifier=___ when building
ahh
The native host you get there is just
dotnet.exe renamed, though
need the msbuild parameter
it is still a program linked to the Console subsystem
yes that is for another case
in my case an Orleans service which will run in containers
so basically this renamed dot net will be direct executable without need to pass the .dll as a parameter right?
Right, you just open it directly
perfect
thanks
will take a note
It looks for a
.dll next to itself with the same name, and then hosts the CLR and uses that dll as the entrypoint assembly
perfect
I guess for the Console problem, people (for now) will need to build their own hosts
:(
Yeah... personally I think it's really unreasonable to expect anyone to do that, because of how complicated
dotnet.exe is and how many platforms you'd need to build for. That's why I am hoping we will come to some sort of conclusion in that issue I linked
Technically you could just fork core-setup and change the subsystem linkage of dotnet.exe, and then publish a nuget package with a different name
humm
yeah
As far as I'm aware though, you'd then need to do additional work to get this custom host to play nicely with the new SDK targets, although I tried to ask them to make it easy/possible to integrate
At the very least you could just inject a custom post-build target to rename things and copy your custom host in on Windows
I’ve dealt in the past with mono when I had to create the host… it was a pain :(
@mellinoe hey
I don't suppose you know why on dotnet core when I do
Process.Start( FolderName)
I'm getting Win32 Exception Access Denied
Hrm, what is
FolderName? seems weird to be passing that to Process.Start
Is that supposed to be opening an explorer window there?
I believe the difference here is that
UseShellExecute defaults to false in .NET Core instead of true, so we are attempting to launch that folder as an executable rather than create an explorer there
You can either set
UseShellExecute to true, or you could do Process.Start("cmd", $"/c start {FolderName}");
in full dotnet you could pass a path
like Process.Start("c:\myfolder\")
and it would just open in explorer
would also work on mono
ok let my try use shell execute
Yeah, the relevant difference is that we default
UseShellExecute to false, so it doesn't work on .NET Core. You can set that manually in the ProcessStartInfo or you can use the above command
man you know your stuff
Thanks, it's just my job ;)
oh another quick think while I have your attention
is it possible to use runtime text templates (.tt files) in .net core?
or can you possible recommend a text templating thing that can be used with .net core
@mellinoe
In my opinion the right thing to do is unconditionally link dotnet.exe against the Windows subsystem, and then conditionally create a console window based on some metadata in the project
That won't work
@mellinoe last question… have we got at some point with making .net core apps to run as daemons or windows services? (I’ll not bug you again! :P)
If exe has console subsystem
It won't be attached to the console
Of the calling process
AllocConsole will just allocate a new one
We've tried to mess with that back in VB6 days
So changing subsystem by patching PE is the only way
@danwalmsley On linux the command would be
xdg-open
@kekekeks thanks
@galvesribeiro what exactly prevents us from P/Invoking StartServiceCtrlDispatcher
@kekekeks how long til your .net core branch can be fully merged?
Well, grokys doesn't feel well
@kekekeks you mean to register it with svcctl?
TopShelf uses direct registry access, I think
Yeah, it doesn support .net core yet
@danwalmsley I'm not really aware of runtime text-templating options, unfortunately. Perhaps take a look at this? https://github.com/lunet-io/scriban
That's because it uses built-in service class from .NET
Which isn't available
@kekekeks Could you elaborate on the subsystem problem? I didn't quite follow
You see, if you start something from powershell/cmd or another process that has proper console
And started executable has CUI subsystem
It will inherit standard handles from that process
So stdin/stdout/stderr will be reused, unless redirected
That won't happen if process has GUI subsystem
Topshelf/Topshelf#277
CUI subsystem = console subsystem?
Yep
You can allocate a new console by calling
kernel32!AllocConsole
So what you're saying is there's no way for dotnet.exe to tell if the parent process already had a console to use?
So it would end up creating an extra console?
That doesn't depend on dotnet.exe
Handles are being inherited before executable's entry point is called
My idea was that dotnet.exe could determine if it needed a console after running some code, though. Could it not check if there's already a console before calling
AllocConsole?
It won't have access unless it has CUI subsystem
Like, call this thing: https://msdn.microsoft.com/en-us/library/ms683175(VS.85).aspx, if it returns
NULL, then call AllocConsole
If I remember correctly, it doesn't matter
Since std handles aren't attached to parent's console
Interesting. I'm outside my element here so I'm mostly just guessing. It feels like there should be some way to accomplish this :worried:
Do you know how Visual Studio is able to have both run modes?
Console and GUI
What do you mean by that?
Run attached to console when started from command prompt
And run without console when started by shortcut
I don't think there's any difference. It's a GUI application that doesn't create a window if you pass certain command-line args
Visual Studio has 2 executables
- devenv.exe which is started by shell
- devenv.com which has priority when cmd.exe wants to start devenv
You can't have one executable that can run in proper console and GUI modes
You either can't access to parent's console or have to deal with freshly created console window when started from non-console application
That's how windows works
You might be right, I'm beyond my level of understanding here
hi guys, sorry for not getting the .NET core PR merged yet - I can see there's a lot of interest!
I'm feeling much better today
I have some errands to run this morning but will be able to review and hopefully merge this afternoon
in the meantime if anyone else wants to review please go ahead and add comments!
How many owners are there that can merge?
there are 5 core team members
good, having only one could be a problem when the project goes take-over-the-world-scale :)
yeah if it were just me that wouldn't be good
@grokys pr from a functional point of view is looking good
Avalon studio is porting across quite easily
it's not building for me on 2015 - is it 2017 only?
i'll let you know if I find anything that doesn't work
I think you have to install .net core rc3
let me find the link
ah that would make sense
then if it still doesn't work, you might need vs2017
will still build from command line though
stuff seems to run quicker
and use less memory
yep, that builds now, thanks
not sure
but I think you have to use skia only?
I think use direct2d wont work for .net core
sharpdx doesn't have .net core nugget package available yet perhaps
i think it does, but there's only a .net standard version of skia so far
that's fine with me for now
i've got to go out now, i've given the code a quick review, but need to actually try to run something using .net core when i get back!
it's not building for me on 2015 - is it 2017 only?
I made sure that PR is building on AppVeyor's VS2015.
I'm using the tooling from this guide — https://docs.microsoft.com/en-us/nuget/guides/create-net-standard-packages-vs2015
I'm not sure what exactly you need to install, since I'm using ASP.NET Core since beta4
I think he got it wokring
Ah, ok
@grokys
https://github.com/kekekeks/avalonia-net-core-example - .NET Core-based example is here. You need to change NuGet.config to point to your nuget package output directory
https://github.com/kekekeks/avalonia-net-core-example - .NET Core-based example is here. You need to change NuGet.config to point to your nuget package output directory
thanks @kekekeks !
you know i really dislike shared projects
if only visual studio could somehow show the files that get included as part of a shared project it'd be fine
but as it is, they're like hiding source files
@kekekeks is this useful for implementing
GetLoadedAssemblies in .net core? http://www.michael-whelan.net/replacing-appdomain-in-dotnet-core/
@grokys yes it is
we used that in Orleans
@grokys tried that
i don't know if it's better than the code that's already there: https://github.com/AvaloniaUI/Avalonia/blob/d0e691554231517246e342fe740d6c42b6555a8b/src/Avalonia.DotNetCoreRuntime/NetCoreRuntimePlatform.cs#L16
ah ok
AppVeyor said something like
"I'm sorry, Dave, I'm afraid I can't do that"
haha ok
was working perfectly fine on my machine though
That was the original version of the code
not managed to get the nuget packages build on the .net core branch
A stable release of a package should not have on a prerelease dependency. Either modify the version spec of dependency "SkiaSharp [1.56.1-beta, )" or update the version field.
An error occurred when executing task 'Create-NuGet-Packages'.
Error: NuGet: Process returned an error (exit code 1).
(i'm building from cake)
You need to add
-something postfix
to your package version
Try with
--force-nuget-version=0.4.2-testbuild1
BTW, I think
Create-NuGet-Packages target should depend on Build
Not on
Run-Unit-Tests
yeah, and it shouldn't do a clean every time either
Well, that's arguable
Currently any target runs a reproduceble build
and makes sure that there are no leftovers from the previous one
Cake script Clean main function is to create directories if they don't exist
whooop, got it running!
yeah, i dunno, sometimes i just want to build changes with cake. not very often though tbh as usually i do that in VS, so /shrug
anyway, the .net core build isn't that straightforward, but it works!
hopefully it will work out of the box on 2017
@grokys removing this line should probably fix the issue with Clean https://github.com/AvaloniaUI/Avalonia/blob/master/build.cake#L588
this folders are created by msbuild anyway
and this can be removed too https://github.com/AvaloniaUI/Avalonia/blob/master/build.cake#L102
thanks, it's not a big problem
ok
just meant that i had to do a complete build again instead of just rebuilding the nuget packages
I usually just comment out that dependency when I'm debugging package generation
yeah, that's what i've done before
BTW, we need to split that script
It's too huge
Also too much work is done outside of targets
ok, PR looks good. i'm kinda wary about including something that's such a WIP in master, but it's obvious that there's an awful lot of interest in getting this working so I think that's more important
Well, it's not WIP
It works)
Just need to fix icons in win32 backend (for some reason we are using Windows.Forms for them) and implement window states for GTK3
Oh, also folder selector in said win32 backend
But that could be done as separate PRs, since current one is already 38 commits
BTW, we need to split that script
@kekekeks I can try to split cake build script
merged!
Thanks!
Are we going to announce it on reddit or just wait for alpha5?
yeah we could, but we'd need to put together some decent instructions first i think
That depends on alpha release plan, I think
@kekekeks do you have twitter so i can mention you?
Do we want scenegraph to be in alpha5 or not
well i was intending to do an alpha5 before
scenegraph
Not using it heavily or something
what i meant though was just instructions for building from source for .NET core
Well, we have an example for VS2015 tooling
i hope we can have proper .net core support in the release after alpha5 though
I could add one for VS2017
right, but e.g. i had to install 2 versions of .net core SDK previews, pass a command-line argument to cake, clone your sample app, update the path to the nuget packages there etc
just instructions such as those because everyone will hit those problems
Well, now that packages are published to nuget, you don't need to do all that to use avalonia from net core app
just install VS2017, reference packages and you are ready to go
Well, let's wait for alpha5 then
i dunno, i think it would be good to publicize that we've got it working when building from source
One could use our nightly feed, you know
instead of building the whole thing from source
I'll update my example project to do that
ok great
as much as I hate to say that, but those new MSBuild projects on latest RTM tooling is really nice… very compact without mambo jambo
yeah i can't wait!
@grokys the MSBuild tooling is released
the VS2017 isnt
:)
@galvesribeiro RC3 isn't exatly a "release"
it's a "release candidate" =D
The .NET Core and ASP.NET Core workload is no longer in preview. We have fixed several bugs and improved usability of .NET Core and ASP.NET Core Tooling.
The RC4 is Visual Studio tooling
not .net core
All I see here is RC3
it is VS tooling
it is a mess those versioning
they already announced on a community meetup
the tooling is done and released. the only part in RC is VS tooling (just a bunch of UI wrappers aroung the underlying tooling) and they now stopped to work on it and are working on
netstandard2.0
unless Damian passed the wrong impression to eveyone listening :)
everyone knows that a "release candidate" in MSspeak is a beta ;)
hehehe
anyway, the latest tooling is being very stable here… even with VS2017 crazyness
https://github.com/kekekeks/avalonia-net-core-example - updated example with proper feed url and some docs
@wieslawsoltes any chance of making xaml behaviours target .net core too?
@danwalmsley you should be able to reference PCL from your project
Ah I think once it references new avalonia will be ok then
You also need to switch to nightly feed, I think
ok
I vote to get scengraph in alpha 5!
it would be nice!
It would postpone alpha5 release for a month
@danwalmsley have you encountered
DllNotFoundException: Unable to load DLL 'libSkiaSharp':?
yeah, it would be nice but even once it's finished i suspect it'll take a while to work out all the bugs
Mkay, my VS install got completely broken
I'm unable to save files
@kekekeks AvaloniaUI/Avalonia#878
Why do you need to explicitly pass/access
context ?
there no access for static helper methods
they are available only in main script
Cake project does the same
I wonder if it's possible to have nuget feeds on per-PR basis
@wieslawsoltes any chance of making xaml behaviours target .net core too?
@danwalmsley I have updated XamlBehaviors to latest Avalonia build
@kekekeks iv not had that on windows
On Linux id get it if ld library path isn't set
I'm getting it with VS2017 and .NET Core 1.0-
Works fine with 1.1
Iv only used 1.1
@wieslawsoltes nice one, thanks
I still wonder if we should wait for alpha5 or just go and claim the title of "The first UI framework for .NET Core"
I think you should wait until everything is settle up and people can use the new tooling
otherwise, you will have tons os people jumping in to contribute and they can’t use the new tooling they have
nobody wants to install old tooling anymore
Yep, true
At least untill you are confortable to update everything to use new tooling I would keep it quiet for now :)
(which I would do now if I were you :P )
I think we can claim that title, although may e skiasharp.views might also claim?
nah
it is a a fully feature UI framework
You see, Skia.Views are targeting specific frameworks
yeah but they will change
and
there is https://github.com/mellinoe/ImGui.NET though
as far as I know, Skia.View rely on the underlying platform UI kit, so it is not fully feature and independent UI framework like Avalonia
"First .net core Xaml UI framework"
So we are basically waiting for AppVeyor to provide VS2017 images
you dont need it
you can grab the SDK while building
Can you just get appveyor to install .net core rc3
I have Docker.Dotnet doing that
it still using preview4 btw… I’ll update it to the latest one later
but it is the same principle, just replace the URL with the RC4
you dont need VS2017 for it
appveyor/ci#1179 we could request access to their "beta" image here
ok, but you dont need
You see, installing stuff as a part of the build process
Slows down your builds quite significantly
It will get cached won't it?
that installation is very simple and fast
don’t even bother to cache it
and it is temporary
Its just temporary measure until appveyor catch up
dotnet cli takes at least 20 secs on the first run after installation
that is the nuget cache
you can cache it no problem
regardless of the tooling
I'll request access to their VS2017 image and see what we can do with that
and man, what is so critical that 20s would kill ? :P it is temporary
I’m not sure if even with their 2017 image they have the latest tooling there
VS Tooling != .Net SDK tooling
Visual Studio 2017 RC image has been updated to the latest RC3 (build 26127.03) released on February 1, 2017
we are on RC4
:)
on VS tooling I mean
they will always lag anyway
Well, I'd prefer to use the same tools that are installed on my laptop, you know
:+1:
Got a bit sick of trying to figure out what's wrong on AppVeyor
yeah, it is kinda, weird...
Tbh, the only CI agent/service that I like is one from TFS/VSTS… all others are a pain to figure out what is going on
Well, let's here @grokys's thoughts on this matter. His main concern was the current state of VS2017, but it got better with the last update
VSTS?
Seriously?
yep
seriously
It treats stderr output as actual errors
use it today and compare with jenkins, appVeyor, MyGet and you will see
Really? do you know it is configurable, right?
My favorite one is TeamCity anyway
Where?
I've spent hours looking for that option
in the build task options
I ended up with this code in my cake build script:
[System.Runtime.InteropServices.DllImport("kernel32")]
static extern IntPtr GetStdHandle(int handle);
[System.Runtime.InteropServices.DllImport("kernel32")]
static extern IntPtr SetStdHandle(int num, IntPtr handle);
[System.Runtime.InteropServices.DllImport("kernel32")]
static extern IntPtr CloseHandle(IntPtr handle);
var stderr = GetStdHandle(-12);
var stdout = GetStdHandle(-11);
SetStdHandle(-12, stdout);
CloseHandle(stderr);
Console.SetError(Console.Out);
cake...
I don’t write a single line of code to build :)
in the build task options
There is an option for continuing build, but it will still be marked as "partially succeded"
вроде все слова понятные... но что происходит не ясно :)
I don’t write a single line of code to build
From my point of view that's an awful thing
build, release, CI, CD, everything there… I’m happy with it
unfortunately it isn’t open
The ideal build configuration is one that calls a build script
the ideal code is the one you didn’t write :D
anyway
Yep, but it's nice to be able to migrate between build systems at will
endless debate
:)
and you can
The gitlab Ci is pretty good, but I think you can only use with gitlab
You can use your own machines
export the tasks with a powershell script and be happy :)
To run builds so no queuing if you don't want
Excuse me please very much! On habr you wrote that Avalonia uses Skia to render, and on github it's written that it uses direct2d... what is right?
@Igor_Gritsenko_twitter renderers are pluggable
Right now we have Direct2D, Skia# and Cairo
.NET Core version uses Skia#, since SharpDX isn't compatible with .NET Core
IMHO we should wait until 2017 is released before we move to it
i don't want to install 2017 on my main machine because i don't trust it not to break anything yet
i have it installed on another machine for when i have to use it
Oh. it's clear now. And skia# has no problems to run with Core? Or you have to build skia it also for net core?
They just released a version a few days ago with .net core support
@kekekeks has moved very quickly
@Igor_Gritsenko_twitter Skia# doesn't have prebuilt native buinaries for Linux. We are currently using our own
See instructions there
thank ю вери мачъ!
Basically we already had almost everything in place and waited for Skia# to provide NETStandard-compatible build
@grokys come on, I'm using VS2017 for some of my production projects
It can't be that bad
ha, me too, and i have found it that bad! :)
@grokys I'm using vs2017 for all my production projects... because I have small ssd)
seriously, it hangs for 5 minutes on the first build that has an error
FIVE MINUTES
i've not updated to RC3 yet
hopefully they've fixed that
there must be something wrong on your deployment @grokys it never happened to me
I’m using it since the very first releases
clean install of windows, clean install of VS
@grokys just think about those juicy
TypeConverters
it had tons of problems
but nothing that a quick restart in it hasnt resolved
are you using it for developing VS extensions? i suspect that might be where the problem lies
I always wanted to counte the number of exceptions thrown when starting a clean install of vs on a clean windoze
VS extension development have always been a mess
I recently updated Orleans Extensions to VS2017 and didn’t had problems
tell me about it
Regardless of VS version
@kekekeks
VS extension development have always been a mess
True story
@kekekeks what's required to have mac support for .net core?
GTK3 build
It should work with one from
brew
But I haven't checked yet
Ah ok
@galvesribeiro do you have a mac?
I probably messed up with library name postfix formatting though
@danwalmsley yes
Maybe we can test Avalon studio on it later
I'll
Mkay, since .NET Core requires stuff from
brew anyway, we should be fine with using it for now
openssl frmo there
The thing I don't like about
brew is that it makes /usr/local/* writable by user acccount
Yep, I've messed up name resolution
Or not
Well, it almost worked
Yeah, almost
We need pixel format transformations after all
pretty close!
Well,
SkBitmap::CopyTo should be able to handle that
But after that's fixed it will basically run out of the box
The only thing that I did (aside from installing .NET Core tooling) was
brew install gtk+3
Nice work getting NetCore support! I'm excited to try it out once my power returns :(
@galvesribero, btw, people don't need to install "old tooling", VS2017 works with current solution just fine
Since there are no projects that are using .NET Core
I’m not sure about that...
if you have latest tooling installed, it will not work with old (project.json/xproj) based solution
I have a specific case right now
I’m using the latest version and I’m on latest updates, and Orleans doesn’t have updated yet to it
There is no xproj )
it doesnt build and all the files in Solution explorer are gone
project.json or xproj
Csproj + project.json
We are using UWP tooling
IIRC that is broken as well… project.json don’t work
with latest tooling
Worked half a hour ago with latest vs2017
already told you
VS2017 != .Net SDK tooling
Meh, just clone solution and open it
With vs2017
unless you start doing that magic mabo jambo with global.json to force use old SDK
it will not open, I don’t have that sdks anymore here, only the latest
No global.json)
and I’m baging my head here with something in docker
will try it later on
We are stuck with netstandard1.5, but this project type works with vs2015 and vs2017
this is what happens
they are all csproj with project.json
many of them are PCLs
but will try avalonia later
So why does it work for me
because you are not in the latest tooling
I have vs2017 and net core rc3 installed
Where can I get that RC4 thingy?
or because you have the previous SDKs installed as well (old tooling) probably
RC4 is latest
1m
What is your output from dotnet --version ?
1.0.0-rc4-004597
if you are going to try it, be aware that it will break your environment if you dont update the projects
unless you have all other previous tooling installed
The old tooling I’m refering to
that feeling when you get solution from github of of AvaloneUI for .net core and it runs out of the box from the first time
sorry :-)
hehehe
nice
@wieslawsoltes
Package Avalonia.Xaml.Behaviors 0.4.1-build329-alpha is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1) / win-x86. Package Avalonia.Xaml.Behaviors 0.4.1-build329-alpha supports: portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
One or more packages are incompatible with .NETCoreApp,Version=v1.1 (win-x86).
Meh, just use target fallback
remve the RuntimeIdentifie while in development as well
you dont need it
put is as a conditional tag so it is only included while targeting release and publishing
conditional tag
It will download a metric ton of binaries anyway
@danwalmsley Try latest build
Yay!
:D
Unfortunately that involves unnecessary intermediate bitmap
curious @kekekeks the pixel format conversion made with SW without HW accell, right?
Since for some reason Skia is unable to just copy and convert pixels to arbitrary memory location
Our Skia renderer is SW-only for now
ah ok
It's possible to enable HW-accel
But I'm not sure that we need to
optimizations are always good :)
Since last time I've checked it sometimes caused performance degradation
Really?
Because of the way that Skia renders text in HW mode
They are using font atlases
but I’m happy it work without HW accell because it can work on my HW :P
Ouch!
That's why we have to be very careful about what we are rendering on GPU
I wonder if chrome uses it for fonts on Skia or if it use some other library for it and paint only the bitmap
and what on CPU
I think that once we'll get
scenegraph merged
We could start work on GPU support
Since only and composition/effects should be rendered there
ic
Chrome does not use HW-acceleration for everything
It's mostly used for scene composition and effects there
Text, basic shapes, etc are rendered in SW-mode
hmm
@grokys Do we need pull requests for things like that — AvaloniaUI/Avalonia#879 ?
i'd say so - best to run it through CI
if it's a really minor change then you can disable the protected branch on master if you like, but i usually do a PR anyway
I wonder if it's possible to just merge directly if CI checks have passed
Nope, not possible
don't think so: though like i say you can disable the protected branch temporarily
It would be a good feature for GitHub BTW
it's nice to have the extra context for commits that PRs give too though
Ability to merge without PR
tbh i don't think they'd do it - protected branches are there so that you need to create a PR, merging without one is kinda defeating the point
Well, we are mostly using them to make sure that CI checks pass first
That's a valid use case
though this suggests it might be possible: https://help.github.com/articles/about-protected-branches/
but sooo many times since i started at GH i've used the fact that all changes go though a PR to get extra context for a commit
of course it's not so helpful if the PR message is left blank ;)
Well, commit message speaks for itself
commit message says what the change does, but a PR description can answer questions like "why did we need to make this change?"
so something like "running on iOS we discovered that the default pixel formal was displaying wrong, so blah blah" etc
BTW
AvaloniaUI/Avalonia#877
Why do you think that ShowDialog can be implemented in xplat way?
On linux there is even a special window property
That tells the window manager that some window is modal
ah yeah, that's a really old issue.
There also some logic in OSes that prevent modal dialogs to be lower than their parent
i'm guessing there was a lot of stuff in the platform-specific part that could be made x-plat
We need to pass window parent though
So we could call
user32!SetParent, gtk_window_set_transient_for, etc
We need to go through "old issues" to see if they are still valid
Or we'll get people wasting their time
And put a huge red notice somewhere saying "Before picking an issue to work on consult in gitter chat blablabla"
BTW, @grokys
There are cases when ITopLevelImpl is being called after disposal
There are cases when ITopLevelImpl is being called after disposal
See
GtkWidget.IsClosed checks here: https://github.com/AvaloniaUI/Avalonia/blob/master/src/Gtk/Avalonia.Gtk3/TopLevelImpl.cs
They mark the methods that are being called after disposal
Contributing
Before You Start
Drop into our gitter chat room and let us know what you're thinking of doing.
Should be in README.md, I think
there's a link to it under "Contributing" in the readme
A big red warning on top of the issues/pull requests page would be a nice feature for GitHub...
i think they may be currently thinking about how to better get people "started" with contributing
i've pinged you on the PR if you want to add your input
So you are executing a layout pass inside render cycle
where?
Here
+ Measure(Size.Infinity);
+ Arrange(new Rect(DesiredSize));
that was already happening
Wow,
async tests. The Future is here
the visual brush stuff has on
scenegraph has to change though anyway
i've still not quite figured out the best way to do it
Last time I was touching that code, I was just copy-pasting it to some class shared across backends. Still don't understand, how it actually works
BTW, we need some docs on how scenegraph works, I wasn't able to find the place where layers are being created
And criteria for their creation
yeah i know... sorry things have just been changing too much
there will be docs soon
but as for the layout thing on visual brushes the problem comes when you have something like:
If I understand correctly the basic idea is to have some "shadow" of the visual tree
And then split that shadow tree to layers
yep, currently a layer is only created when you have opacity
Are you checking for
ClipToBounds?
so if you e.g. change the opacity of a
UserControl then its contents don't need to be redrawn, just the layer with the new opacity
Because being in a layer kinda forces that clipping
so if you e.g. change the opacity of a UserControl then its contents don't need to be redrawn, just the layer with the new opacity
I think that's how Chrome currently works
right. that's why at the moment layers are the size of the window: because there may be stuff outside the bounds
it's less than ideal
yeah, i looked at chrome's devtools and it seems to create a layer on opacity
though they're intellegent and the layer is only the size it needs to be
we can do that, but it will come later
If
ClipToBounds is true, you can safely reduce the size of the layer
yep, but we actually have the bounds of the actual subtree available so we can also do it even if cliptobounds is false
Would be nice to have layers tab in devtools
yep!
And it will be a killer-feature for presentations
When you need to talk about rendering, just create some slider bound to opacity/rotation and show people how layers are being created
yeah, you can actually see it working in controlcatalog at the moment though
when a tab fades in/out it doesn't redraw the children
we also can do things like merge sibling controls with the same opacity into a single layer etc too
atm disabled buttons use opacity (not ideal i know) but this means that if you have two disabled buttons on a window, then 3 layers are created
you really only need 2
i also really want a way to do viewport scrolling so that you don't have to redraw everything on scroll
not sure what the API for that would look like though!
You definetely need a separate layer for scrollable area then
yeah
Since you probably won't be able to access previous frame contents
i don't think WPF or UWP have that
but i don't know if you noticed in the
RenderTest sample - it has proper geometry hit detection
Btw another feature from chrome we should bring over is a way for a control to specify that it needs a render layer (for controls that do 3d rendering or video presentation
)
Does retained renderer run in a separate thread?
@jkoritzinsky yep, there will definitely be a way to do that - we can borrow WPF's syntax i think
@kekekeks yep
So how that exactly works? Controls are provided with a fake DrawingContext?
yeah exactly
Also, optional platform implementations for the render layers like kekekeks and I talked as a possibility about a while ago?
What happens if control needs RenderTargetBitmap?
@jkoritzinsky would ILockedFramebuffer be enough for that?
Maybe...
So it would be something like
WritableBitmap from WPF
The main issue with "direct" rendering to layer would be locking
There are a few specific cases I'm thinking of. Can I run them by you and you can tell me if they might work with that?
at the moment layers are
IRenderTargetBitmapImpls but this isn't good on D2D
So we need to provide double buffering anyway
as they're WIC-backed bitmaps which need conversion to show in D2D
so i'm thinking we need something like
IRenderTargetBitmapImpl IRenderTarget.CreateLayer() which on D2D would create a D2D bitmap
would that work for you @jkoritzinsky ?
Partially...
The main situations I'm thinking of are 2 things
I think that we need to provide some sort of negotiation protocol
Between subsystems
Something like
IWindowImpl::Surfaces
On OSX for AvaloniaAV, the AV player object only renders to a NSView or a CALayer
With emulated framebuffer being default one, since it's universally accessible
One idea is using the render layers backed by a render target bitmap or a frame buffer as a fallback and allowing platforms to supply platform specific render layers
Like DirectComposition when on Windows 8+ or CALayer on iOS/macOS
Mkay, so, in case of OSX and Skia
How are we supposed to provide that CALayer?
SkiaSharp.Views has an implementation of skia on a CALayer
We can always pull from there
It renders to CALayer, not vice versa
I'm really not sure then.
Skia could always use the default fallback
this is for showing video right?
That's the use case I'm currently looking at
BTW, could you tell me exact class name that can draw to CALayer?
SKGLLayer?
so what use-cases do we have? 1. render layers 2. video layers
wouldn't video playback be implemented entirely in the rendering subsystem though?
- 3d interop/embedding
You see, that class renders to OpenGL context provided by CoreAnimation
I know
There is no way of accessing another layer's contents from skia
I think I may have mis worded what I meant
Unless we do some voodoo magic with opengl FBOs
Have Quartz/CoreGraphics (on OSX/iOS) use CALayers
Instead of everything on those platforms
I'm not sure that you can manually compose CALayers from CoreGraphics
But it might be worth to use CoreAnimation directly
That sounds good to me
So, basically you suggest that we draw everything to CALayers
And then let coreanimation do the composition
Yep. Like 1 CALayer for each render layer
And then compose with core animation
that is how the appkit does, right?
As far as I know yes
you can even “debug” the layers individually in runtime
That will require scenegraph to not compose layers direclty
And let drawing platform do that instead
And we do the composition on platforms that can't do it natively (IE skia and d2d on win7)
I think iOS and Android does it
dunno about OS X itself
Android doesn't have API for controlling that
OSX is very similar to iOS in terms of lower level rendering libraries
You are stuck with Views, not layers
humm
I wish I could met you guys before :)
I would love to see AngleSharp being used in a xplat C# browser engine
today what is missing is the rendering
well everything i know about this i learned from @kekekeks in a previous convo
this guys has an awesome HTML and CSS lib
plugable JS engine...
Awesome
what he misses is plug together HTML and CSS libraries and create a library to create the render three
I’m very dumb with UI stuff, so I didnt even try
I spoke with the creator, a nice guy
unfornutalye he dont have much time to dedicate
I see one issue with external layer composition
What?
For example you have something like
<StackPanel Background="Red" Padding="10">
<Button Opacity = "0.5"/>
<MySuperControl ClipToBounds="False"/>
</StackPanel>
In this case a layer is allocated for Button
they are 3 layers
But
MySuperControl expects to draw on top of that Button which is now a separate layer
Oh...
I see it
If we are doing manual composition, we control the order of drawing operations
Do we draw background, draw layer and then draw
MySuperControl
But if we want to use external composition
We need to introduce a lot more layers
How does chrome handle this issue? Or it is not relevant for them?
In this case one for StackPanel, one for Button and one for MySuperControl
That's a good question for investigation
And I'm not sure that
MySuperControl drawing on top of Button is a valid scenario anyway
Since I would expect it to draw on StackPanel, but not on the Button
But what if it needs some glow effect?
Because our last conversation we were using chrome as our example when you first showed me the perf considerations for using native render layers
Maybe take a look at how WPF does it?
From performance point of view there is no much difference between native layers and manual composition
We were talking about layer per visual or limiting rules for when to create render layers
Yep, I remember that
But we were talking about layers in general, not native/manual layers in particular
True true
Could we potentially have native layers for only controls that really need it and use manual ones in other situations?
Or is that not practical
I'm not super experienced with advanced rendering contexts.
*concepts
I'm not sure that we can mix them this way
From rendering system's point of view native layers are no different from native child windows
And since they allow alpha-channel for child windows since Win8
(Linux had that since forever)
There is no difference at all
Ok. Because I'm not sure how some interoperability scenarios would work efficiently without native layers since they'll already designed to work together: Video rendering and D3D11 swap chain embedding for 3d rendering
Native layers become an issue if you want to paint on top of them
The difference between child windows and composition layers is that composition layers can be transformed with affine transforms (which I don't think you can do with win 32 embedded windows)
Yep, but that's not related to z-ordering issue
I understand that. We need to figure out if that's a use case we need to support (just like these other ones)
So we need to create some kind of a list of cases when you want to paint on top of another layer
And check if there are valid ones there
But painting on top of sibling control is a valid one for sure
You might want to drop shadow from menubar, etc
Yep. And check if there are efficient ways to do the use cases that require native layers with manual ones instead
Or if we even want to support those other use cases
So, basically we need to check if we can have a separate "composition system"
BTW, said separate compositor will be good in general, since it will allow to use HW-acceleration to compose SW-drawn layers
I agree I think that would be good
How do other frameworks that use the layers manage the shadow issue?
No idea
CALayer has built-in shadow support
See
shadow* prefixed properties
If we go down this road, I think that we should design our layer system using CoreAnimation as a reference
And in case of Direct2D1 we could still use our own composition implementation
Could we use DirectCompositon on win8+ and use a fallback impl on win7?
Since you only need D2D bitmaps to be exposed
You see, the more backends we have, the more we are prone to bugs
True
And more affected by limitations of said backends
And we need a manual one for skia anyway
So if we could compose the scene manually and if it doesn't impose any limitations
We should go for it
Ok.
I get that
Unless there are some components that require you to use
DirectComposition
Not as of now. But I can't think of another good way to get a dxgi swap chain to render to a d2d bitmap without going through DC in some way
My last windows-related HW-acceleration experience comes from DirectX 9 times, so I can't make an educated choice here
Maybe we should make a wiki page and try to do some research and collect it there?
Or create an issue
And we definitely need a summary of this discussion
Yes
Can you create it and put start the summary? I'm away from my computer right now( typing this on my phone)
So the plan for now is to use RenderTargetBitmaps as layers and once scenegraph is complete we can see if it's possible to extract some kind of separate composition system
Well, it's 2:45AM here...
Oh right time zones. I'll put the summary together
yep, i've been unable to comment as i'm not knowledgeable enough, but that sounds good to me
BTW, could adorner layer be a solution for "paint-over-sibling" issue?
Adorners are rendered in some layer that's on top of an element or a group of them
Right now the adorner layer renders on top of everything
Not on top of individual controls
Does it have to be that way?
And it might actually be OK
It doesn't have to be. That's just how it is today.
Out-of-borders and on-top-of-everything painting is needed mostly for user interaction
In conclusion. The main question is:
Can we have a separate render step that composes layers, or do we need to mix render composition with drawing operations?
Can we have a separate render step that composes layers, or do we need to mix render composition with drawing operations?