awesome! i will merge that then
@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
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?
I don't think so
well we could draw a line and a triangle i'd have thought
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
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
@grokys Please, take a look at #899
If it's OK, I'll start cleaning up platform implementations
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
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?
yeah, something like that is what i was thinking
to be clear: rather than these methods https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Platform/ITopLevelImpl.cs#L56-L91
instead, just set a listener and call stuff though an interface, that delegates to protected methods
Selection in a link? What kind of sorcery is that?
haha, you've never seen that before?
Nope
just select lines and the URL updates
Doesn't seem to work in FF
strange - it should!
I'm doing something wrong
Aha, it works with SHIFT
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
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.
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
yeah that sounds good to me: .net core for alpha 5 then big new features for beta 1
I thought there would be "pre-beta" release
We even have a milestone for that
yeah or we can do that too
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
But
It would be extremely fun
To run a live demo of avalonia in browser
wow amazing demo @kekekeks are you sure you're not a robot?
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
wow!
how did you do that?
that would indeed make a very cool demo!
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
ah ok, yeah i thought i remembered seeing it, but couldn't remember how it was done
And doesn't support session multiplexing
Since now we have a GTK3 backend, you can do that with our netcore demo
btw, i was reading this: https://www.cairographics.org/threaded_animation_with_cairo/
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.
Meh, that's actually not an issue, we'll just send render results to UI thread
yeah
And I don't think that we need their built-in opengl support
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?
You see, in case of desktop, it can be just an implementation detail
at the moment surfaces are
objects
and that's only for SW rendering
EGL has no issues with rendering from a separate thread
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
I'm still trying to figure out if it's OK to render to a
CAEAGLLayer from non-ui thread
however if you don't do threaded rendering then if the window hasn't been resized you just need to render the pixmap
Well, regardress of rendering mode
We still need a way to force immediate render pass
And that would involve some locking
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
To make sure that two threads aren't trying to render simultaneously
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
Does separate thread renderer needs anything from the main thread?
Because we could just send a request to the render loop
no
and wait for render pass to complete
well the render loop is currently shared between all windows
Using a blocking
Task.Wait() call or something
but even if it weren't shared, i think that you'd still see a lagging black border
That's not an issue
shared loop, I mean
ok, well it sounds like what you're suggesting already happens then
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
i don't follow. are you saying >1 renderer per window?
1 renderer per window
But you need to activate a particular one
while render loop deals with multiple renderers
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
There is no actual difference between rendering from UI thread
And waiting on a blocking wait call
ah ok i get you
From the point of view of windowing system
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
Ehm
I thought that update to the graphs comes before rendering
So UI thread updates the graph, then enters wait mode
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
It won't, if graph doesn't need to be updated
And in this case it's up to date
but during a resize the graph will need to be updated
Resize event comes before expose
so update the scene graph in the resize event and then wait in the paint event?
Yep
yeah, that should work
We also need a way to tell render thread, that we are waiting for it
So it won't bother sending messages
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?
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
right so that's why i thought an e.g.
IRenderSurface.SupportsThreadedRender would make sense
Render surface is selected by rendering subsystem
Inside
CreateRenderTarget
There is no way to tell which one will be used
right but the render surfaces are exported by the windowing subsystem, which knows right?
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
ok, if it can be hidden in a surface, even better
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
ok, sounds like we should be ok then
(assuming we can handle deallocated surfaces)
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
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
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
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
hmm, to be honest i'd be fine with having to do something like
((Win32.WindowImpl)window.PlatformImpl).Hwnd to get a HWND
Yeah, but that might be not possible to do from non-ui thread
Need to read more about GTK's thread safety
i'm showing my ignorance about GTK here, but does GTK expose a Windows HWND?
yep
firing up VS to take a look
gdk_win32_window_get_handle
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
@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
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