These are chat archives for AvaloniaUI/Avalonia

21st
Oct 2017
Nikita Tsukanov
@kekekeks
Oct 21 2017 14:39
Nikita Tsukanov
@kekekeks
Oct 21 2017 14:44
AvaloniaUI/Avalonia#1240
I haven't touched any code in DeferredRenderer itself
Steven Kirk
@grokys
Oct 21 2017 15:45
cool!
Nikita Tsukanov
@kekekeks
Oct 21 2017 15:48
Ehm, I was trying to show rendering artifacts
on progressbar
That are still present on OSX for some reason
BTW, there is a problem with rendering from background thread on OSX
For some reason when I call lockFocusIfCanDraw from non-UI thread
window contents don't get clipped properly
Resulting in square window corners
Steven Kirk
@grokys
Oct 21 2017 15:49
oh, i thought you were showing the fact you've got the deferred renderer working on monomac
Nikita Tsukanov
@kekekeks
Oct 21 2017 15:50
That causes flawed window border and minor flicker on resize
Since main event loop still redraws the window, but with proper rounded corners and transparency
It gets redrawn with square ones on the next render loop tick
but it's still visible
I'm not sure how to handle that properly
BTW, according to AppKit's release notes from OSX 10.13
Rendering from outside of the main loop is discouraged
Steven Kirk
@grokys
Oct 21 2017 15:53
ok, so we need to enable deferred rendering on main thread then
doesn't it work if you just make the render timer tick on the main thread?
Nikita Tsukanov
@kekekeks
Oct 21 2017 15:54
The recommended approach is to push rendered frame back on UI thread, I think
Steven Kirk
@grokys
Oct 21 2017 15:54
ah ok
so you can render on a background thread, but rendering to screen needs to be done on the UI thread?
isn't that's what already happens for GTK?
Nikita Tsukanov
@kekekeks
Oct 21 2017 15:56
For GTK I'm using a separate X11 display connection
And calling XPutImage from background thread
That works quite well
Steven Kirk
@grokys
Oct 21 2017 15:59
ok, so what do you need? would a flag in deferred renderer to say "render to offscreen bitmap and draw that bitmap on Paint" work?
Nikita Tsukanov
@kekekeks
Oct 21 2017 15:59
Well, that could be handled by framebuffer abstraction
And for hw-accelerated rendering we'll need to render in background thread anyway
Since CVDisplayLink actually ticks on non-ui thread
I haven't checked what happens to the window border though
Nikita Tsukanov
@kekekeks
Oct 21 2017 16:33
Mkay, another issue
During window resize PerformSelectorOnMainThread doesn't actually work
Nikita Tsukanov
@kekekeks
Oct 21 2017 17:04
@grokys Cocoa has quite interesting priority system for UI thread
UI thread can enter several modes
One of them is user-initiated window resize
Most of the tasks queued for the main thread won't be executed in this mode
Steven Kirk
@grokys
Oct 21 2017 18:04
doesn't a similar thing happen on windows? from what i remember on resize win32 doesn't go through the standard message loop
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:07
It intercepts NC_MOUSE* events
But still allows messages to be delivered to the window, I think
The problem is that our animations freeze completely during resize
Since render thread is unable to get scene updates
Steven Kirk
@grokys
Oct 21 2017 18:08
hmm
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:08
And even if it could, it won't be able to send rendered frames back to UI thread
Well, it's only during resize, we can probably live with that
the only problem is it lags for one frame during resize
Because NSView::drawRectwon't happen until the next resize
It would be nice to be able to force DeferredRenderer to produce a frame on UI thread
Steven Kirk
@grokys
Oct 21 2017 18:11
yeah definitely
that wouldn't be hard
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:12
I guess it should check if scene can be updated immediately instead of using dispatcher
And it already has some locking
Steven Kirk
@grokys
Oct 21 2017 18:14
would it be as simple as adding UpdateScene to IRenderer and making it public in DeferredRenderer?
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:22
Hm, no idea
I'm not sure that we should add that method to IRenderer
We could make MonoMac backend aware of DeferredRenderer and explicitly call some methods there
I'll try to experiment with that later
I think DeferredRenderer should properly react on Paint event instead
And backends should call that event only when explicitly needed
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:27
BTW, why are you calling ITopLevelImpl::Invalidate from DeferredRenderer?
That makes no sense
Steven Kirk
@grokys
Oct 21 2017 18:34
why doesn't it make sense? shouldn't an invalidation message be sent to the window when its content changes?
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:35
Well, you don't draw anything in Paint handler
And rely on updating window contents outside of the main event loop
So it makes no sense to make Invalidate calls
Steven Kirk
@grokys
Oct 21 2017 18:36
true, i think the idea was that some backends would need to draw in the paint handler though, like we were just talking about
but without that, i agree that we should probably remove the invalidate
Nikita Tsukanov
@kekekeks
Oct 21 2017 18:37
Yep, but that should be handled by the backend itself
Steven Kirk
@grokys
Oct 21 2017 18:37
ok, yeah go ahead and remove it then
Nikita Tsukanov
@kekekeks
Oct 21 2017 23:31
@grokys @jkoritzinsky AvaloniaUI/Avalonia#1242
That should solve our problems with iOS and avalonia modules
We could even remove explicit initialization code for some subsystems (e. g. UseReactiveUI, UseOxyPlot)