These are chat archives for AvaloniaUI/Avalonia

19th
Feb 2017
Steven Kirk
@grokys
Feb 19 2017 00:30
awesome! i will merge that then
Nikita Tsukanov
@kekekeks
Feb 19 2017 17:48
@grokys Skia doesn't support PenStrokeCap.Triangle
And different line caps for begin/end
And doesn't seem to have any plans of adding support for them
Steven Kirk
@grokys
Feb 19 2017 18:10
ok. for the moment i'm fine with saying "skia doesn't support that". though we can probably implement it ourselves in the future, right?
Nikita Tsukanov
@kekekeks
Feb 19 2017 18:10
I don't think so
Steven Kirk
@grokys
Feb 19 2017 18:11
well we could draw a line and a triangle i'd have thought
Nikita Tsukanov
@kekekeks
Feb 19 2017 18:11
That won't work with dashes
We are also skipping several tests because of differences in image scaling quality
Currently there are two things, that are broken in skia
1) Some pen styles
2) NoFill tile brush style
Steven Kirk
@grokys
Feb 19 2017 18:13
well tile brushes are actually completely broken right now
we might be able to fix that when we fix them
for the moment, we should add "not supported by X" to doc comments i think for stuff that's not supported on certain platforms
we can decide later on what do for them - whether to remove, polyfill or leave them not implemented for certain back ends
probably the best way to track missing features though is via skipped tests
Nikita Tsukanov
@kekekeks
Feb 19 2017 18:44
@grokys Please, take a look at #899
If it's OK, I'll start cleaning up platform implementations
Steven Kirk
@grokys
Feb 19 2017 19:06
sounds good. tbh i'd like to also refactor the way the impl passes events back to the toplevel. having loads of Actions etc isn't really scalable
however the methods that the impl calls also shouldn't be public
probably an interface that delegates to protected methods would be best
as if you only have an interface it's not possible to call a base class implementation
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:09

the methods that the impl call

Ehm. I'm not sure that *Impl call anything

Or are you talking about some kind of java-like listener interface?
Steven Kirk
@grokys
Feb 19 2017 19:11
yeah, something like that is what i was thinking
instead, just set a listener and call stuff though an interface, that delegates to protected methods
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:12
Selection in a link? What kind of sorcery is that?
Steven Kirk
@grokys
Feb 19 2017 19:12
haha, you've never seen that before?
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:12
Nope
Steven Kirk
@grokys
Feb 19 2017 19:12
just select lines and the URL updates
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:13
Doesn't seem to work in FF
Steven Kirk
@grokys
Feb 19 2017 19:13
strange - it should!
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:14
I'm doing something wrong
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:19
Aha, it works with SHIFT
Nikita Tsukanov
@kekekeks
Feb 19 2017 19:48
BTW
I've got a 45m slot for avalonia on dotnext conference in St. Petersburg this May
We might want to do some kind of intermediate release before that, since I doubt that remote previewer will be ready until alpha5 (which, if I remember correctly, we are planning to do after VS2017 release) and that's the feature that would be really nice to have available through regular nuget
Jeremy Koritzinsky
@jkoritzinsky
Feb 19 2017 19:54
Maybe push the previewer to beta 1? I think scenegraph branch + remote previewer/remote windows would be a great selling point for a beta release.
Nikita Tsukanov
@kekekeks
Feb 19 2017 20:01
well, we already have a previewer
So it would be just proper support for .NET Core
Which is already a "selling point" for alpha5
And I doubt that we'll get previewer support in AvalonStudio/MonoDevelop in immediate future
AvalonStudio runs on OmniSharp, so it will lack proper access to the project model and metadata
And I can't even build the recent MonoDevelop on my machine
Steven Kirk
@grokys
Feb 19 2017 20:20
yeah that sounds good to me: .net core for alpha 5 then big new features for beta 1
Nikita Tsukanov
@kekekeks
Feb 19 2017 20:20
I thought there would be "pre-beta" release
We even have a milestone for that
Steven Kirk
@grokys
Feb 19 2017 20:21
yeah or we can do that too
Nikita Tsukanov
@kekekeks
Feb 19 2017 20:32
This little trick now works without patches
Still want to have our own implementation, so we could run on top of ASP.NET Core and have multiple sessions
7MB per user session might be too much through
Nikita Tsukanov
@kekekeks
Feb 19 2017 20:37
But
It would be extremely fun
To run a live demo of avalonia in browser
Andrey Kunchev
@donandren
Feb 19 2017 20:42
wow amazing demo @kekekeks are you sure you're not a robot?
Nikita Tsukanov
@kekekeks
Feb 19 2017 20:44
Well
I've got a "I'm not a robot" sticker from one of the stackoverflow guys at a conference...
And then stackoverflow didn't accept the activation code from that sticker
Steven Kirk
@grokys
Feb 19 2017 21:08
wow!
how did you do that?
that would indeed make a very cool demo!
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:10
I think I've already shown that a year ago or something
That's actually Broadway backend for GTK3
It requires a separate display server
Steven Kirk
@grokys
Feb 19 2017 21:10
ah ok, yeah i thought i remembered seeing it, but couldn't remember how it was done
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:10
And doesn't support session multiplexing
Since now we have a GTK3 backend, you can do that with our netcore demo
and you are right, using gtk you shouldn't paint outside the expose event
Eventually, our do_draw will draw to a global GdkPixmap and we will paint this pixmap to the screen upon an expose_event. It is considered good practice to draw on a widget during its expose_event only.
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:13
Meh, that's actually not an issue, we'll just send render results to UI thread
Steven Kirk
@grokys
Feb 19 2017 21:13
yeah
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:14
And I don't think that we need their built-in opengl support
Steven Kirk
@grokys
Feb 19 2017 21:14
but we need a way to signal that we should use this approach
i was thinking of changing surfaces to be an interface, e.g. IRenderSurface or something, and have a property on the surface indicating that this should be done?
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:15
You see, in case of desktop, it can be just an implementation detail
Steven Kirk
@grokys
Feb 19 2017 21:15
at the moment surfaces are objects
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:15
and that's only for SW rendering
EGL has no issues with rendering from a separate thread
Steven Kirk
@grokys
Feb 19 2017 21:16
right, i thought about it being an implementation detail but if this needs to be done, the behavior is still different bceause you need to make sure to paint the pixmap on expose
if you can do threaded rendering, then Renderer.Render will update the scene graph and render in response to e.g. a resize
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:17
I'm still trying to figure out if it's OK to render to a CAEAGLLayer from non-ui thread
Steven Kirk
@grokys
Feb 19 2017 21:17
however if you don't do threaded rendering then if the window hasn't been resized you just need to render the pixmap
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:17
Well, regardress of rendering mode
We still need a way to force immediate render pass
And that would involve some locking
Steven Kirk
@grokys
Feb 19 2017 21:18
yep, that's the difference i was talking about: when i said "render in response to e.g. a resize" that's a "forced" render
yes it will require locking
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:19
To make sure that two threads aren't trying to render simultaneously
Steven Kirk
@grokys
Feb 19 2017 21:19
yep
i guess we can just have Render.Render() which does the paint from pixmap to window, and something like Renderer.ImmediateRender() which does the "forced" render
i think that way it can remain an implementation detail
hmm, no that's not right
because the renderer still needs to know if Render.Render() is a noop
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:23
Does separate thread renderer needs anything from the main thread?
Because we could just send a request to the render loop
Steven Kirk
@grokys
Feb 19 2017 21:23
no
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:23
and wait for render pass to complete
Steven Kirk
@grokys
Feb 19 2017 21:24
well the render loop is currently shared between all windows
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:24
Using a blocking Task.Wait() call or something
Steven Kirk
@grokys
Feb 19 2017 21:24
but even if it weren't shared, i think that you'd still see a lagging black border
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:24
That's not an issue
shared loop, I mean
Steven Kirk
@grokys
Feb 19 2017 21:24
ok, well it sounds like what you're suggesting already happens then
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:25
You just need to change it to use Java-style listener pattern
then you could just pass Renderer instance to the loop
So it will know which one it needs to notify ASAP
Steven Kirk
@grokys
Feb 19 2017 21:26
i don't follow. are you saying >1 renderer per window?
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:26
1 renderer per window
But you need to activate a particular one
while render loop deals with multiple renderers
Steven Kirk
@grokys
Feb 19 2017 21:27
well at the moment, if you just have 1 window and you resize you see a black border during resizing while the threaded renderer catches up
i think to fix that we need to do a "forced" render on the main thread
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:27
There is no actual difference between rendering from UI thread
And waiting on a blocking wait call
Steven Kirk
@grokys
Feb 19 2017 21:28
ah ok i get you
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:28
From the point of view of windowing system
Steven Kirk
@grokys
Feb 19 2017 21:28
ok yeah that might work
problem is that the update to the scene graph needs to be done on UI thread
which will be waiting
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:29
Ehm
I thought that update to the graphs comes before rendering
So UI thread updates the graph, then enters wait mode
Steven Kirk
@grokys
Feb 19 2017 21:30
not quite - if the renderer detects the scene graph needs to be updated, it sends a message to the UI thread to update the scenegraph for the next frame
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:31
It won't, if graph doesn't need to be updated
And in this case it's up to date
Steven Kirk
@grokys
Feb 19 2017 21:31
but during a resize the graph will need to be updated
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:31
Resize event comes before expose
Steven Kirk
@grokys
Feb 19 2017 21:32
so update the scene graph in the resize event and then wait in the paint event?
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:32
Yep
Steven Kirk
@grokys
Feb 19 2017 21:33
yeah, that should work
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:33
We also need a way to tell render thread, that we are waiting for it
So it won't bother sending messages
Steven Kirk
@grokys
Feb 19 2017 21:33
ok, i'll look into that
however going back to communicating that the renderer needs to draw to a bitmap: does an IRenderSurface interface make sense to you?
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:34
I'm not sure that we need that
And windowing subsystem might expose multiple surfaces
And only some of them might need UI-thread-only rendering
Like with GTK on windows
It's perfectly fine to create a Direct2D context on top of HWND
Steven Kirk
@grokys
Feb 19 2017 21:36
right so that's why i thought an e.g. IRenderSurface.SupportsThreadedRender would make sense
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:36
Render surface is selected by rendering subsystem
Inside CreateRenderTarget
There is no way to tell which one will be used
Steven Kirk
@grokys
Feb 19 2017 21:36
right but the render surfaces are exported by the windowing subsystem, which knows right?
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:37
I think that "render-to-bitmap" should be an implementation detail of said surface
Because we don't need it for DirectX+HWND
And skia-based surface implementations should be able to do that internally
Steven Kirk
@grokys
Feb 19 2017 21:38
ok, if it can be hidden in a surface, even better
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:39
In case of GTK and framebuffer we are rendering to memory allocated by Marshal.AllocHGlobal
Same for iOS and SW rendering
On android ANativeWindow supports locking for sw-drawing
so it's capable of passing bitmap to proper thread internally
Android also supports drawing to a surface from non-UI thread
But there is an issue with that
When surface is deallocated for whatever reason
It happens before your code gets a notification
So there is no way to wait for current render pass to complete
so we'll be getting EGL_BAD_SURFACE
Not sure if it will break anything
in case of iOS there is at least a way to share FBO between UI and render thread
I'm not sure if it's ok to swap buffers directly from render thread
Steven Kirk
@grokys
Feb 19 2017 21:45
ok, sounds like we should be ok then
(assuming we can handle deallocated surfaces)
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:46
Surfaces themselves shouldn't get deadlocked
You see render buffer can be only in 3 states
1) used in UI thread
2) used in render thread
3) on the way from render thread to UI thread
So you can safely swap render buffers from (2) and (3)
And that can be done at any moment
So in case where we have 2 buffers (one in state (1), second in state (3))
And have no buffer for rendering
We just wait for a short amount of time (in case it's just some lag) and then allocate a third one
Which should be dismissed afterwards to save memory
But that, again, is implementation detail for GTK/iOS
Steven Kirk
@grokys
Feb 19 2017 21:50
ok, great
if it can all be hidden as an implementation detail i'm happy
i might need your help putting it into practice for gtk though ;)
btw #899 looks good to me from a first look
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:52
I'll just reimplement framebuffer emulation so it will accept calls from any thread
Not sure what to do with HWND getter, through
Because we can't cache it
it's not always available
Steven Kirk
@grokys
Feb 19 2017 21:53
hmm, to be honest i'd be fine with having to do something like ((Win32.WindowImpl)window.PlatformImpl).Hwnd to get a HWND
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:54
Yeah, but that might be not possible to do from non-ui thread
Need to read more about GTK's thread safety
Steven Kirk
@grokys
Feb 19 2017 21:55
i'm showing my ignorance about GTK here, but does GTK expose a Windows HWND?
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:55
yep
Steven Kirk
@grokys
Feb 19 2017 21:56
firing up VS to take a look
Nikita Tsukanov
@kekekeks
Feb 19 2017 21:56
gdk_win32_window_get_handle
Steven Kirk
@grokys
Feb 19 2017 21:58
ah yeah i see it now
i still wonder if we should remove IPlatformHandle and have something like (window.PlatformImpl as IHwnd)?.Hwnd
but that's another topic
Darnell Williams
@Seeker1437
Feb 19 2017 22:36
@kekekeks I really like #900
I was thinking about how it wasn't portable, but I am not talented enough to change it to be portable.
I wanted other IDEs to be able to host it, such as SharpDevelop or Visual Studio for Mac/Linux
Maybe even VSCode
Nikita Tsukanov
@kekekeks
Feb 19 2017 22:51
VSCore probably won't
because of that javascript BS
Well...
We could use ASP.NET Core + Kestrel + WebSockets + SignalR
But that will live in Avalonia.OoohLookAtMeIAmAProgrammingLanguageICanEvenShowWindowsOnDesktopHurrDurr package
And I will release that code on special license terms that won't allow to distribute it with other name
Yeah, sounds like a plan