These are chat archives for AvaloniaUI/Avalonia

26th
Dec 2015
Darnell Williams
@Seeker1437
Dec 26 2015 04:36
random question for anyone who is alive
what would Perspex need in order to be used in Unity?
Nikita Tsukanov
@kekekeks
Dec 26 2015 09:19
Perspex will need Unity devs to abandon their overwhelming greed and puchase an updated license for Mono
Since their current one is 2.6
Geoffrey Huntley
@ghuntley
Dec 26 2015 09:27
What the hell is going on between Unity and Xamarin anyway. I feel like there's no one true story, so much bias.
Nikita Tsukanov
@kekekeks
Dec 26 2015 09:27
No idea
They may as well use coreclr
Which they also not willing to do for some reason
Geoffrey Huntley
@ghuntley
Dec 26 2015 09:35
Going coreclr would make so much sense if they aren't able to work out a amicable deal but unity seem to be going into the compilter/managed language game. Seems like the techs have been let out of the cage.
Unless they are specifically working on the Web browser target platform. No one else is looking after that for. NET. Xamarin is mobile and coreclr is server.
Nikita Tsukanov
@kekekeks
Dec 26 2015 09:36
Well, let them play their games, we won't support just another crappy and incomplete CLI implementation
Geoffrey Huntley
@ghuntley
Dec 26 2015 09:36
Yep don't blame you.
Nikita Tsukanov
@kekekeks
Dec 26 2015 09:37

No one else is looking after that for. NET

Do you have some time to talk about our gods and saviours WebAssembly and LLILC?

Geoffrey Huntley
@ghuntley
Dec 26 2015 09:39
I mean as a prime commerical driver from business perspective. Like Xamarin will neglect mono unless it improves the mobile story. Likewise Microsoft is all about xplat server code now.
Nikita Tsukanov
@kekekeks
Dec 26 2015 09:39
Ehm
MS is one of primary developers of WebAssembly, you know
It's very logical thing for them to add WebAssembly support for C#
For using the same language for server and client
LLILC is also developed by MS
Geoffrey Huntley
@ghuntley
Dec 26 2015 09:46
Why do you think LLILC exists (commerically)?
Nikita Tsukanov
@kekekeks
Dec 26 2015 09:46
Well, LLVM
It's a good platform that's already used by Apple, AMD and other companies
Allows you to cut expenses on your own code generator and get native platform support almost for free
MS C++ compiler is also getting LLVM-based backend
Alexey
@flcl42
Dec 26 2015 10:13
Does any other .net il player for android exists except xamarin's one?
Nikita Tsukanov
@kekekeks
Dec 26 2015 10:13
coreclr is being slowly ported
The problem is that you'll need to generate some java code to wrap .NET stuff
Alexey
@flcl42
Dec 26 2015 10:19
Do you mean just activity wrapper or availability of Java API calls or something else?
Nikita Tsukanov
@kekekeks
Dec 26 2015 10:20
Usually you need to implement a lot of interfaces in your app
For UI we can live with NativeActivity
But stuff like push notifications will be an issue
Alexey
@flcl42
Dec 26 2015 10:45
Sounds weird but in theory nothing prevents me to grab all public entities from android java libraries and generate wrappers for them in c# which will call java methods through ndk function like in http://stackoverflow.com/questions/5198105/calling-a-java-method-from-c-in-android question footer, but with related parameters(like class, method names).
And after adding adapters for unified interface I can then look for solution for ios.
Can't find english analog for "дикий костыль"
Nikita Tsukanov
@kekekeks
Dec 26 2015 10:59
Well, the problem is that you need to somehow support java calling C# code
Because, you know, callbacks
And creating JNI wrappers to everything is exactly what Xamarin does
iOS support is even more tricky because you can't use JIT here
So everything needs to be compiled to native code before deployment to device
Geoffrey Huntley
@ghuntley
Dec 26 2015 11:07
FYI Xamarin android is now AOT
Nikita Tsukanov
@kekekeks
Dec 26 2015 11:07
Wow, so it won't be slow as hell anymore?
Geoffrey Huntley
@ghuntley
Dec 26 2015 11:07
Fix marketing problem whereby people were reversing applications. Aparrently people don't like dotPeek
Nikita Tsukanov
@kekekeks
Dec 26 2015 11:07
Good news
I thought that was only available in "enterprise edition"
Geoffrey Huntley
@ghuntley
Dec 26 2015 11:08
There's a tick box that enables it on the project. Old solutions won't get it because people don't read the release notes and enable it but it's been the default on new solutions for a couple of months.
Nah that was the case, now available on all.
Nikita Tsukanov
@kekekeks
Dec 26 2015 11:11
Summary: don't bother with implementing xamarin-less android/ios support until coreclr will be there, it's not our job
If you are low on funds there is that chineese guy who sells crack with updates for 20 bucks or something
Alexey
@flcl42
Dec 26 2015 11:24
Trial is fine and I ll use it and pay when publish, I just have delusion people should pay only for personal support and library improvements on demand. Cos rest is what free software provides: forum sup, bugs fixing at someday-this-year. Wish rivals for Xamarin.
Nikita Tsukanov
@kekekeks
Dec 26 2015 11:24
Yep, but that's just to much work to get this stuff up and running without xamarin
The only viable alternative is coreclr and it's not even released for desktop platforms yet
Alexey
@flcl42
Dec 26 2015 11:29
I used it for aspnet, it works fine. Different problem is about no libs in nuget for it.
Darnell Williams
@Seeker1437
Dec 26 2015 12:01
One does exist
oh tab fail
There is a working wrapper that is not based on Xamarin but it is very old abd still on API 16
idk if it can be used the way people need to use it..
MIT license
Nikita Tsukanov
@kekekeks
Dec 26 2015 12:19
I don't recommend wasting time on this until somebody gets coreclr run on android
Because if we'll be developing xamarin-less version of Perspex for android it will be based on coreclr
Darnell Williams
@Seeker1437
Dec 26 2015 13:39
gottcha
Steven Kirk
@grokys
Dec 26 2015 14:15
anyone here done much f#?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:20

@grokys Is there a way to cache UseControl in Perspex

    public class RectangleControl : UserControl
    {
        public RectangleControl()
        {
            this.InitializeComponent();
        }

        private void InitializeComponent()
        {
            PerspexXamlLoader.Load(this);
        }
    }

every time the DataTemplate is used the user control is loaded from Xaml :(

        <DataTemplate DataType="core:XRectangle">
            <shapes:RectangleControl/>
        </DataTemplate>
Steven Kirk
@grokys
Dec 26 2015 14:21
i think that's the same in WPF is it not?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:21
well the UserControl is created but I dont think Xaml is parsed
Steven Kirk
@grokys
Dec 26 2015 14:22
i think it is - the ctor for the UserControl will call InitializeComponent in WPF, which loads the XAML
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:28
Well they cache/reuse DataTemplate if previous object was of same type
is it was null than they load
Steven Kirk
@grokys
Dec 26 2015 14:29
yeah, that needs to be implemented
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:31
well I did measure InitializeComponent in WPF and Perspex for same UserControl:
Perspex: 10,8717ms
Perspex: 11,4314ms
Perspex: 10,583ms
Perspex: 11,0801ms
Perspex: 10,6467ms
Perspex: 21,9233ms
Perspex: 23,4482ms
Perspex: 10,6708ms
Perspex: 10,6495ms
Perspex: 17,0344ms
WPF: 3,6119ms
WPF: 6,4401ms
WPF: 2,4281ms
WPF: 2,4458ms
WPF: 2,4655ms
WPF: 2,4102ms
WPF: 2,4383ms
WPF: 9,6975ms
WPF: 2,413ms
WPF: 2,4089ms
WPF: 2,4491ms
WPF: 2,5151ms
WPF: 2,4209ms
Steven Kirk
@grokys
Dec 26 2015 14:34
yep, perspex is still in alpha so such things are expected ;)
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:34
@grokys How can I check when Control was rendererd
after being loaded from xaml
well 10ms is not bad
Steven Kirk
@grokys
Dec 26 2015 14:34
well you can't check when it's been rendered as such
but you can tell when it's been added to the visual tree
which means it will be rendered at the next render
Visual.OnAttachedToVisualTree
or the Visual.AttachedToVisualTree event
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:35
and if it was added to visual tree, that means it was measured ?
Steven Kirk
@grokys
Dec 26 2015 14:36
no, the layout takes place shortly before the render
what do you need to do?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:37
to try figure what has slowed down
it takes a lot of time before DataTemplate is dispalyed on screen
and Xaml initialization takes only 10ms
Steven Kirk
@grokys
Dec 26 2015 14:38
it's probably the layout
layout is really in need of optimization
you can enable logging to see how long the layout passes take
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:39
how I do that ?
Steven Kirk
@grokys
Dec 26 2015 14:39
put something like this in your App ctor
            Log.Logger = new LoggerConfiguration()
                .Filter.ByIncludingOnly(Matching.WithProperty("Area", "Layout"))
                .MinimumLevel.Verbose()
                .WriteTo.Trace(outputTemplate: "[{Id:X8}] [{SourceContext}] {Message}")
                .CreateLogger();
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:40
InitializeComponent: 10,6134ms
MeasureOverride: 209,9205ms
MeasureOverride: 0,0645ms
ArrangeOverride: 6,0592ms
did use Stopwatch :smile:
layout is to blame :(
Steven Kirk
@grokys
Dec 26 2015 14:41
yep, thought so
i know it sucks every time i open the DevTools
i've taken a look a few times to work out why its so slow
but i can't work out why
at least, WPF should be just as slow
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:42
InitializeComponent: 10,2853ms
MeasureOverride: 213,3076ms
MeasureOverride: 0,0645ms
ArrangeOverride: 6,0374ms
Render: 0,0002ms
Render: 0ms
InitializeComponent: 10,2707ms
MeasureOverride: 208,4385ms
MeasureOverride: 0,065ms
ArrangeOverride: 6,0221ms
Render: 0ms
Render: 0,0002ms
Render: 0ms
Nikita Tsukanov
@kekekeks
Dec 26 2015 14:43
@grokys have you seen rendertransform+culling bug in our testapp?
Steven Kirk
@grokys
Dec 26 2015 14:43
hmm, wonder what introduced that?
Nikita Tsukanov
@kekekeks
Dec 26 2015 14:43
This message was deleted
Steven Kirk
@grokys
Dec 26 2015 14:44
probably the clipping stuff
Nikita Tsukanov
@kekekeks
Dec 26 2015 14:44

MeasureOverride: 213,3076ms

Measure is super slow

Steven Kirk
@grokys
Dec 26 2015 14:44
yep
Nikita Tsukanov
@kekekeks
Dec 26 2015 14:44
It takes ages to switch tabs on ios
Steven Kirk
@grokys
Dec 26 2015 14:44
i don't understand why... it uses the same algorithm as WPF
yep, it's the culling stuff that broke the animations. fuck
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:46
Tested in WPF:
InitializeComponent: 3,7271ms
MeasureOverride: 5,2149ms
ArrangeOverride: 1,3071ms
Render: 0,0002ms
MeasureOverride: 0,0002ms
ArrangeOverride: 0,8796ms
InitializeComponent: 2,4706ms
MeasureOverride: 4,9464ms
ArrangeOverride: 1,2387ms
Render: 0,0002ms
MeasureOverride: 0,0005ms
ArrangeOverride: 0,8483ms
InitializeComponent: 2,4427ms
MeasureOverride: 4,9592ms
ArrangeOverride: 1,2426ms
Render: 0,0002ms
MeasureOverride: 0,0002ms
ArrangeOverride: 0,8678ms
InitializeComponent: 2,4317ms
MeasureOverride: 4,9177ms
ArrangeOverride: 1,2628ms
Render: 0,0005ms
MeasureOverride: 0,0005ms
ArrangeOverride: 0,854ms
InitializeComponent: 2,423ms
MeasureOverride: 4,9909ms
ArrangeOverride: 1,2554ms
Render: 0,0002ms
MeasureOverride: 0,0005ms
ArrangeOverride: 0,8399ms
Steven Kirk
@grokys
Dec 26 2015 14:47
so how is WPF so fast? what's taking up all the time with Perspex?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:47
no idea, I'm using almost same Xaml controls in WPF and in Perspex
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 14:53
@grokys Did try to log one pass for UserControl http://pastebin.com/nW5VsXdb
Steven Kirk
@grokys
Dec 26 2015 14:54
looks all normal
i don't understand why that takes .33 of a second though!
Alexey
@flcl42
Dec 26 2015 15:08
caching probably
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:18
Guys, I've found a flaw in this
/something is parsed by mono as file:///wat
Dunno how to workaround that
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 15:21
Przechwytywanie.PNG
@grokys This is interesting
Przechwytywanie1.PNG
Steven Kirk
@grokys
Dec 26 2015 15:22
well it depends what that child can be
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:23
@grokys I think I'll be implementing resm:Full.Path.To.Resource;assembly=Assembly
Steven Kirk
@grokys
Dec 26 2015 15:23
ah was just about to ask you what you thought of that proposal
Johan Larsson
@JohanLarsson
Dec 26 2015 15:23
@grokys Reed writes close to 100% f# since a couple of years I think
Steven Kirk
@grokys
Dec 26 2015 15:24
yeah, i think it makes sense as the url:// format is for hierarchical resources, and manifest resources aren't really
so using a similar format to clr-namespace makes sense to me
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 15:24

well it depends what that child can be

http://pastebin.com/G4zwXyHE

Nikita Tsukanov
@kekekeks
Dec 26 2015 15:25
One day we'll have hierarchial asset support
Steven Kirk
@grokys
Dec 26 2015 15:25
yep, hopefully!
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:25
It can be done via msbuild task that adds an additional resource with path mappings
So, technically it will be the same, but we'll be using intermediate path translation
Steven Kirk
@grokys
Dec 26 2015 15:26
might be worth just trying to get the resources that WPF uses supported in mono/monodevelop
they seem to have the classes for reading them
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:26
Yep, but they don't have required MSBuild task
Steven Kirk
@grokys
Dec 26 2015 15:26
might be just md that doesn't support them
yeah
so that sounds do-able
it'll be good to have manifest resource support anyway
maybe can also add resx resource support too etc
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:27
I thought that resx is the same thing
Steven Kirk
@grokys
Dec 26 2015 15:28
i'm not entirely clear on the different types of resources, but i think resx are the ones added from the property pages
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:28
In generated code-behind file it uses GetManifestResourceStream
Add something in resx and see generated C# code
So we aren't using Uri class in asset loader anymore, right?
Steven Kirk
@grokys
Dec 26 2015 15:30
we are
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:30
Ehm
Steven Kirk
@grokys
Dec 26 2015 15:30
we can change it
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:31
csharp> new Uri("resm:Full.Path.To.Resource;assembly=Assembly").AbsolutePath
"Full.Path.To.Resource;assembly=Assembly"
wtf
Mkay, I'm ok with that
Steven Kirk
@grokys
Dec 26 2015 15:31
i assume Uri should handle non-hierarchical urls
adding resources via property pages uses System.Resources.ResourceManager
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:32
It seems that "scheme:path" strings are parsed correctly
Steven Kirk
@grokys
Dec 26 2015 15:32
good; i'd assume they were
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:33
resm:/Full.Path.To.Resource;assembly=Assembly
Hm
Now I'm not so sure about slashes
well, let's use clr-namespace-like syntax
Steven Kirk
@grokys
Dec 26 2015 15:37
i know what's wrong with the culling - silly mistake
will fix it hopefully today, but there are kids and family around, and it's making thinking difficult!
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:40
resm:Perspex.Themes.Default.ScrollViewer.paml?assembly=Perspex.Themes.Default
Something like that, right?
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:45
What is IScrollable?
Steven Kirk
@grokys
Dec 26 2015 15:47
IScrollable is what I called IScrollInfo
because it's not "info"
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:47
Mkay, but it uses physical units for mouse wheel
Steven Kirk
@grokys
Dec 26 2015 15:48
basically it says "this control handles its own scrolling"
it can use physical units, pixels, whatever
mouse wheel support is to come
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:49
On mobile platforms mouse wheel events currently use logical pixels
Steven Kirk
@grokys
Dec 26 2015 15:50
are you asking because mouse wheel scrolling is broken somewhere on mobile?
as far as i know, it shouldn't have affected anything else as nothing currently uses IScrollable in Perspex
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:50
It will be weird with current IScrollable implementation
Steven Kirk
@grokys
Dec 26 2015 15:51
yeah, i need to add a method to IScrollable for mousewheel
and scrolling by line etc
it was just a proof of concept really, because AvalonStudio needed something
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:51
It should be "ScrollByPixels" instead of mousewheel, I think
Or somethink like that
Steven Kirk
@grokys
Dec 26 2015 15:52
yeah, i have a plan
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:52
We also need something for inertial scrolling
Steven Kirk
@grokys
Dec 26 2015 15:52
yeah...
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:53
From my point of view it's better to only have smooth scrolling
Steven Kirk
@grokys
Dec 26 2015 15:53
for mousewheel i'm going to just add a single method that takes an enum value that has flags for direction and the unit of movement, i.e. page, line, wheel
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:53
So IScrollable will always use pixels
Steven Kirk
@grokys
Dec 26 2015 15:53
well IScrollable by definition uses logical units, so its up to the implementer to decide what that means
logical units can equal pixels if the implementer wants to do that
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:54
That might cause issues with inertial scrolling
Steven Kirk
@grokys
Dec 26 2015 15:55
true
we should probably advise to use pixels
from my own experience i can imagine times where logical scrolling is more important than supporting inertial scrolling
so we should support both
maybe an IScrollable.SupportsInertialScrolling flag
Nikita Tsukanov
@kekekeks
Dec 26 2015 15:59
It should be UsesPixels then
Steven Kirk
@grokys
Dec 26 2015 15:59
yeah, or that
on another subject i was thinking about our rendering
and thinking how the roslyn immutable stuff enables multi-threading
which would be needed for rendering on a separate thread
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:01
Remember that roslyn has a lot of memory traffic caused by that
Steven Kirk
@grokys
Dec 26 2015 16:01
and the more i read about it, the more i kept hearing that the roslyn immutable API sounds like a "zipper"
yeah, but it's tracking a lot of data
if we had an immutable data structure, i think we could decrease memory traffic
as things can be cached until they're invalidated, thrown away and finalized
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:03
Well, we can't have Render called outside of UI thread
Steven Kirk
@grokys
Dec 26 2015 16:03
no, that's the beauty of it
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:03
So the best approach is to record drawing calls
In some structure
And then pass it to render thread
Steven Kirk
@grokys
Dec 26 2015 16:04
what i was thinking was a low-level immutable scene graph
a separate library to perspex
Render calls invalidate their node in that scene graph, but the rest of the graph stays the same
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:05
wait a minute, there was an article about how chrome handles that
Steven Kirk
@grokys
Dec 26 2015 16:06
YES! exactly!
wow, i've not read it in detail but it sounds very similar to what i was thinking
that scene graph would hold the geometry for each node
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:06
The problem is that we can't do that because our controls render themselves
Steven Kirk
@grokys
Dec 26 2015 16:07
but if "rendering themselves" means:
Render calls invalidate their node in that scene graph, but the rest of the graph stays the same
then we don't have a problem
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:07
Yep, that can be used for bitmap caching purposes
Steven Kirk
@grokys
Dec 26 2015 16:08
yeah, and smooth scrolling
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:08
The problem is that you can't keep each control cached in a bitmap (like iOS does)
Because there are too many of them in the visual tree
Steven Kirk
@grokys
Dec 26 2015 16:09
i assume we'd use a similar technique to html
or even WPF
where controls get rendered to an intermediate bitmap based on certain criteria
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:09
In WPF bitmap caching needs to be enabled explicitly
Steven Kirk
@grokys
Dec 26 2015 16:09
yep
in html it happens when a transform is applied
so people use transform(0) to mean "cache this element"
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:10
Common cases of RenderObject that warrant the creation of a RenderLayer:
  • It's the root object for the page
  • It has explicit CSS position properties (relative, absolute or a transform)
  • It is transparent
  • Has overflow, an alpha mask or reflection
  • Has a CSS filter
  • Corresponds to <canvas> element that has a 3D (WebGL) context or an accelerated 2D context
  • Corresponds to a <video> element
Steven Kirk
@grokys
Dec 26 2015 16:11
exactly
and imagine - you've got a text editor, and the user scrolls down a line
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:13
You still need to re-render your whole text
because you can't keep 1MB file rendered in memory
Steven Kirk
@grokys
Dec 26 2015 16:13
rather than re-rendering everything, you say "scroll the existing content up x pixels and draw this line at the bottom"
because the content is cached, the new cache then becomes the cached content
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:14
Yep, good old user32.dll!ScrollWindow does that
Steven Kirk
@grokys
Dec 26 2015 16:14
yep. even like the NES did that ;)
Darnell Williams
@Seeker1437
Dec 26 2015 16:15
You guys rock
Steven Kirk
@grokys
Dec 26 2015 16:15
so anyway, the more i read about roslyn's immutable API, the more i kept hearing "that sounds like a zipper"
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:15
But I still don't see how that helps with background-thread rendering
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:15
Since controls still render themselves in UI thread
Steven Kirk
@grokys
Dec 26 2015 16:15
nope, controls render themselves to an immutable data structure
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:16
So we'll be recordering rendering commands
Steven Kirk
@grokys
Dec 26 2015 16:16
kinda
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:16
Which is, actually, just a regular list of commands
Steven Kirk
@grokys
Dec 26 2015 16:16
i was thinking that if you had a node:
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:17
It's not about immutability, it's about not touching stuff from UI thread after it was passed to render thread
Steven Kirk
@grokys
Dec 26 2015 16:17
bounds: 10,10,100,100, geometry: Rectangle 10,10,100,100
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:17
Immutable data structures has a lot of memory and memory traffic overhead
R# don't use immutable data structures, for example
Steven Kirk
@grokys
Dec 26 2015 16:17
not if you re-use existing nodes in the scene graph
if you change that one node
the rest of the nodes in the graph don't change
all that changes is the links between them
which should use less memory
Darnell Williams
@Seeker1437
Dec 26 2015 16:18
Yeah I leanred about that for F# but I don't like the idea for the overhead. But in the regards of reusing, why not just make it mutable then? It will reduced the overhead even more
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:19
Basically we need some visual tree that can use System.Collections.Immutable for tracking child nodes
(i could be wrong here - this is all new stuff to me)
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:19
and two copies of rendering commands, one that's currently used by render thread and one that's pushed by UI thread from last render command (can be the same)
Steven Kirk
@grokys
Dec 26 2015 16:20
yeah: because the nodes underlying that structure are immutable, they can be 99% the same between calls
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:20
Nodes themselves are mutable, just thread-safe
Steven Kirk
@grokys
Dec 26 2015 16:21
nope, nodes are immutable
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:21
The thing is that recreating the whole node hierarchy just because you've changed control color is a bad idea
Darnell Williams
@Seeker1437
Dec 26 2015 16:21
What advantages does the immutable node system really have?
Steven Kirk
@grokys
Dec 26 2015 16:21
you can re-use the nodes for the rest of the tree when one control redraws itself
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:21
You are guaranteed to have thread-safety
that's the only advantage
Steven Kirk
@grokys
Dec 26 2015 16:21
and ^^^ that
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:22

re-use the nodes for the rest of the tree when one control redraws itself

You don't need nodes to be immutable for that

Darnell Williams
@Seeker1437
Dec 26 2015 16:22
Oh
SOmething really nice to have
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:22
You just need to use ImmutableList<T> for keeping the list of children
Darnell Williams
@Seeker1437
Dec 26 2015 16:22
AH so the immutable node system could reduce or remove the need for stuff like Dispatcher?
Steven Kirk
@grokys
Dec 26 2015 16:23
not really, no
Darnell Williams
@Seeker1437
Dec 26 2015 16:23
AH okay
Ronald Adonyo
@afrog33k
Dec 26 2015 16:23
@grokys why not just do something like reactjs … virtual node hierarchy and do a diff for updates ?
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:23
@ImaBrokeDude the idea is to have some data structure that can be used by render thread almost without locks
Steven Kirk
@grokys
Dec 26 2015 16:24
@afrog33k i don't think anyone would use that system if they had a choice...
Darnell Williams
@Seeker1437
Dec 26 2015 16:24
Ah I see yeah
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:24
That's actually a good thing
We can have a tree with 2 states
Or just 2 trees
Steven Kirk
@grokys
Dec 26 2015 16:24
well we already have multiple trees
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:25
Wait, let me explain
Darnell Williams
@Seeker1437
Dec 26 2015 16:25
Theoritically allowing multithreaded rendering which is a massive speed increase
Steven Kirk
@grokys
Dec 26 2015 16:25
but we don't have do do diffs to keep them in sync
Darnell Williams
@Seeker1437
Dec 26 2015 16:25
without all the locks and synchronizations?
Steven Kirk
@grokys
Dec 26 2015 16:25
yeah
Darnell Williams
@Seeker1437
Dec 26 2015 16:26
I see now..
Steven Kirk
@grokys
Dec 26 2015 16:26
i would like to speak to @ReedCopsey about this, to see if it's 1) a good idea and 2) a good match for F#
Darnell Williams
@Seeker1437
Dec 26 2015 16:26
Well when reed first mentioned it,
I started digging into it and trying to learn
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:27

There should be 3 different trees

1) UI-thread tree
2) intermediate tree
3) Render-thread tree

Each frame UI thread gets a lock on intermediate tree and copies stuff to it, then it notifies render thread. Render thread also gets a lock on intermediate tree and copies changes to its own one. Then render thread has it's own copy of the tree that it's free to use

Child node lists are ImmutableList<T>, bounds are value types, render-command lists are also immutable
This way we'll get optimal performance and memory traffic
Ronald Adonyo
@afrog33k
Dec 26 2015 16:28
@kekekeks thats what I was thinking as well, clean state, no locks and high performance … all the immutable stuff i’ve tried lends to high memory usage
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:28
Copying references to immutable lists and render command list is super fast
It won't hold locks for more than several nanoseconds
Steven Kirk
@grokys
Dec 26 2015 16:29
hmm
i guess i was just wanting to try doing something in F#
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:29
render command list can be stored in a regular List
Because it uses the same approach as in StreamingGeometry
Once recorded it can be packed in some class that won't allow changes
The only thing that we actually want to change often and reuse is child node lists
Darnell Williams
@Seeker1437
Dec 26 2015 16:30
But from my understaning they use the diff system in #F gui stuff
Steven Kirk
@grokys
Dec 26 2015 16:31
so you guys don't think that a proper functional scene graph library would be a good idea?
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:31
It might be a good idea in general
But using immutable structure for the whole render three?
It will consume too much resources
Darnell Williams
@Seeker1437
Dec 26 2015 16:31
Better a compromise
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:32
Each time you apply transform to a node the whole sub-hierarchy needs to be recreated
Steven Kirk
@grokys
Dec 26 2015 16:32
i don't think it does
Darnell Williams
@Seeker1437
Dec 26 2015 16:33
if it's immutable why wouldn't it be?
Steven Kirk
@grokys
Dec 26 2015 16:33
well roslyn is immutable
but it doesn't recompile the whole project each time you press a key
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:33
There are some algorithms that allow you to save memory reusing nodes
Ronald Adonyo
@afrog33k
Dec 26 2015 16:33
yes, and to change anything … you have to recreate the nodes
Steven Kirk
@grokys
Dec 26 2015 16:34
have any of you guys done F#?
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:34
BTW, parsing documents doesn't happen 60 times per second
Animations do
And roslyn is often criticised for poor performance
Steven Kirk
@grokys
Dec 26 2015 16:35
well animations wouldn't require changing the tree if they're just matrices - you just need to supply an easing function
you give the scene graph a start time, end time and a function and the animation runs itself
Darnell Williams
@Seeker1437
Dec 26 2015 16:36
I have a question
idk if this even makes sense
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:36

you give the scene graph a start time, end time and a function and the animation runs itself

I already don't like that

Ronald Adonyo
@afrog33k
Dec 26 2015 16:36
yes, but maybe you want a hybrid system, have you seen this talk by frank krueger ? https://www.youtube.com/watch?v=_Qk7ZcyYZwA
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:36
Because changes are supposed to happen in UI thread
Darnell Williams
@Seeker1437
Dec 26 2015 16:36
that was the video I watched ^^^
Steven Kirk
@grokys
Dec 26 2015 16:37
@afrog33k this would be a hybrid system: I'm not talking about the whole of perspex being immutable
just the low-level scene graph
Darnell Williams
@Seeker1437
Dec 26 2015 16:38
AH I thought it would have been the whole graph, so where would you draw the line between being immutable/muttable
Steven Kirk
@grokys
Dec 26 2015 16:39
@kekekeks but what if animations didn't have to happen in UI thread? it would be much smoother if there didn't have to be the back-and-forth
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:39
The thing is that they might depend on some state that belongs to UI thread
Steven Kirk
@grokys
Dec 26 2015 16:39
@ImaBrokeDude controls would "draw" to an immutable scene graph
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:40
Example: a ball that follows the cursor
Steven Kirk
@grokys
Dec 26 2015 16:40
right, and for those you'd control them from the UI thread
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:40
What about animating properties like Width?
Steven Kirk
@grokys
Dec 26 2015 16:40
but if you're animating a fly-in say, then why not do that completely in the render thread?
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:40
That actually changes nodes
And will cause graph rebuild
Steven Kirk
@grokys
Dec 26 2015 16:41
in HTML/CSS you have CSS animations which are simple animations
and js animations which are more complex but use more resources
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:42
I'm afraid that UI-thread animations will be too ineffective comparing to JS animations
Steven Kirk
@grokys
Dec 26 2015 16:43
that doesn't need to involve the UI thread
anyway, it was just something i was thinking about
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:45
The thing is that browsers don't use immutable functional scene graph
Darnell Williams
@Seeker1437
Dec 26 2015 16:45
I like the idea
Steven Kirk
@grokys
Dec 26 2015 16:45
they don't, no
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:45
And roslyn is criticised for low performance
Steven Kirk
@grokys
Dec 26 2015 16:46
yep, and i'm willing to be convinced that performance would be low
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:46
When I've first read about immutable data structures I've tried to use them everywhere
Darnell Williams
@Seeker1437
Dec 26 2015 16:46
There has to be a better approach for this :(
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:47
Well, we might take a conservative approach of passing the list of drawing commands to the render thread
It won't have any issues with memory traffic because these commands can be stored in value types in some pooled container
Which is pooled
So once 2-10 command lists get to their capacity there won't be any allocations
And scene graph thingy can be kept in UI thread, since we will need it anyway
Steven Kirk
@grokys
Dec 26 2015 16:49
but that way, you can't reuse the rest of the tree when something changes - if they're value types
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:50
Any immutable data structure have performance and memory issues
That's the tradeoff of not worring about threading
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:51
@kekekeks yup can have immutability and perf, but usage requires a lot of care
Steven Kirk
@grokys
Dec 26 2015 16:51
aha! here he is! ;)
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:52
Roslyn actually has pretty amazing performance characteristics, but it's doing a lot
Steven Kirk
@grokys
Dec 26 2015 16:52
yeah, to me roslyn seems a lot faster than R#
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:52
But, I'm not sure rendering should be immutable at a low level
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:52
@grokys they can't open R# solution in VS2015
Because roslyn can't handle it
At all
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:53
It is... they have a 50ms time budget
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:53
R# team is still using VS2013 to develop R#
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:53
R# doesn't use roslyn
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:53
Yep
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:53
They have their own compiler chain
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:53
The thing is that they can open R# source code with VS2013 with R# installed
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 16:53
But that's due to feature set, not perfect
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:53
And actually develop things
VS2015 can't open R# code base
Because roslyn uses too much memory
Steven Kirk
@grokys
Dec 26 2015 16:54
so, reed, an immutable scene graph in F# that uses the zipper pattern to replace nodes that have changed wouldn't have good enough performance in your estimation?
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:55
Guys, are you even listening or just keep telling me that roslyn is amazing?
Steven Kirk
@grokys
Dec 26 2015 16:55
we're not talking about roslyn ;)
i'm not set on this idea!
it's just something i've been thinking about
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:56
BTW, what benefits that immutable scene graph has over conservative approach?
render-thread-based animations?
Steven Kirk
@grokys
Dec 26 2015 16:56
that i'm getting sick of C# boilerplate? is that a good enough reason?
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:57
So you just want to try F#
Steven Kirk
@grokys
Dec 26 2015 16:57
that's part of it!
Johan Larsson
@JohanLarsson
Dec 26 2015 16:57
There is no going back from trying f# :)
Steven Kirk
@grokys
Dec 26 2015 16:57
and lets be clear: i'm NOT saying "lets do this"
Johan Larsson
@JohanLarsson
Dec 26 2015 16:57
That I have seen
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:58
I've read a book about F# and still use C#
Steven Kirk
@grokys
Dec 26 2015 16:58
it's just something i've been thinking over
i have no idea where i'd start though
so it's purely in the realms of "what if"
Nikita Tsukanov
@kekekeks
Dec 26 2015 16:59
The point is that we can have "render command recording" almost right away
Without much changes for the code base
Steven Kirk
@grokys
Dec 26 2015 16:59
yeah, of course
this wouldn't be like a 1.0 feature even if it were a good idea
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:00
And UI-thread-based scene graph is also quite independent from everything else
We need to get them first
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:00
Well, you can use F# and not go fully inmutable, too
You can write stuff the same way as in c#, though you do lose advantages
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:01
Because it will allow us to get significant performance boost without breaking much of the code base
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:01
I'm not sure a fully immutable render system is the right approach, though I love the idea
Steven Kirk
@grokys
Dec 26 2015 17:02
would it be possible though, to do it like roslyn in the sense that the nodes were immutable and so assuming that only 1 of 100 controls changes between frames, 99% of the nodes were reused
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:02
Most existing rendering systems layer... so they sometimes have an immutable or partial immutable system with pieces internally that mutate between frames
Yeah... possible to do
Especially since animations aren't the norm
Steven Kirk
@grokys
Dec 26 2015 17:03
possible to do... but...?
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:04
Guys, just keep in mind that we might be limited by 128MB or something like that
Steven Kirk
@grokys
Dec 26 2015 17:04
but... easier to do non functionally?
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:04
before using functional styles, immutable trees and stuff
Steven Kirk
@grokys
Dec 26 2015 17:05
yeah, sure -- i'm thinking that reed's lack of enthusiasm means it's a no-go
but i'd still like to hear about how it'd be done
and whether F# would make it easier
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:05
Hahaha... I'm a pragmatist. I'd love to see a hybrid system
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:05
BTW, that immutability might cause tearing and flickering
When some part of the scene changes before render thread gets it's copy of the scene graph
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:06
And, if I were writing something in managed code, starting from scratch, I'd definitely use F#
Steven Kirk
@grokys
Dec 26 2015 17:06
i can't even get a data structure set up in F# so far ;)
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:07
Because I'd love to see a system where you don't have to worry about threads
Steven Kirk
@grokys
Dec 26 2015 17:07
yeah, me too... but sounds like the disadvantages would outweigh the advantages
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:08
My ideal would be to have render be on its own thread, but all abstracted, and updates be external. .. but that could be done without many disadvantages IMO
Steven Kirk
@grokys
Dec 26 2015 17:09
right, that sounds like what i was thinking.. maybe?
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:09
How so? Biggest issue would be that all updates would be async operations
But that's easy to handle from c# on the user's side
And relatively easy to manage in f# with async work flows
Steven Kirk
@grokys
Dec 26 2015 17:10
i'm not entirely sure exactly how
;)
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:10
Toughest part would be making the api nice to use from c#
Steven Kirk
@grokys
Dec 26 2015 17:10
but suppose you had a scene graph separate to the graph of controls
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:11
It doesn't even have to be separate ;)
Steven Kirk
@grokys
Dec 26 2015 17:12
and say for simplicity each node was something like type Node = { Bounds: Rect; Geometry: IGeometry; Children: Node list }
i was thinking in terms of a separate library even
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:12
Okay
Steven Kirk
@grokys
Dec 26 2015 17:13
ok, so you have a tree of these Nodes and each Control has a reference to its Node
one control gets invalidated
its Render method gets called, which replaces the Geometry
the rest of the tree has the same Nodes - just the tree relationships are updated to "slot" in this new replacement Node
bceause the structure is immutable, the render thread doesn't know anything about this
meanwhile the UI thread goes along and makes its changes
and then just before rendering a new frame, the new tree gets swapped into the render thread's tree
99% of the nodes are the same
just the relationships have changed
of course the fact that the Children members have changed means that the nodes themselves have changed
which is the problem
but i'm assuming there's a way around that?
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:17
It'll be tricky to not churn memory
Steven Kirk
@grokys
Dec 26 2015 17:17
right
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:17
That's always tricky with immutable collections
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:18

How so? Biggest issue would be that all updates would be async operations

Oh, now we'll be using TaskCompletionSource

And that stuff is supposed to speed-up thing, yeah
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:19
Well. .. I'd write it in f# using async work flows personally. ..
Async doesn't speed it up, but it makes it easier to segregate work and keep more of it off render thread
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:20
Guys, I don't see why we can't just send some commands to render thread without maintaining big-ass thread-safe complex data structure
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:20
Yeah, that's what I'm saying
Protect render thread by making all interactions controlled through Async api
Steven Kirk
@grokys
Dec 26 2015 17:21
@kekekeks i'm not making a proposal here!
i'm just trying to find out more about my idea
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:22
You can even make the changes effectively immutable if you want to work through keyed items
Wpf sort of has some immutable stiff, BTW. .. it's just done horribly
Steven Kirk
@grokys
Dec 26 2015 17:23
yeah the IFreezable stuff?
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:23
Yeah
Steven Kirk
@grokys
Dec 26 2015 17:23
the thing that started me on this train of thought - and it's a very vague train of thought
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:24
I'd look at openscenegraph, BTW
Steven Kirk
@grokys
Dec 26 2015 17:24
was the "immutable tree with an mutable facade"
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:24
They have thread safe, multithreaded rendering
Steven Kirk
@grokys
Dec 26 2015 17:24
i think openscenegraph would be way more complex than we'd need, and it's in C++ which means binary blobs
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:25
Well, just meant in terms of inspiration
Steven Kirk
@grokys
Dec 26 2015 17:25
ah ok
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:25
Not to use ;)
Steven Kirk
@grokys
Dec 26 2015 17:25
tbh, like @kekekeks says we have most of the stuff in place and it's pretty simple
but y'know I like to think about different ways to do stuff
when i'm out running
but "immutable tree with an mutable facade" -- i've only seen that in roslyn
is that a common pattern in say F#?
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:27
No
F# tends to prefer immutabity
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:27
Immutability is a good thing when you have tons of RAM and want stuff to be processed on 32 cores
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:27
If writing in f#, you'd probably design it differently
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:28
Because it really saves you from using locks and allows better parallelism
Steven Kirk
@grokys
Dec 26 2015 17:28
it's just when reading the comments on roslyn a few people said "that sounds like the zipper pattern"
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:28
But when you have RAM limits and can use only 2 cores
meh
Steven Kirk
@grokys
Dec 26 2015 17:28
so i just wondered if it was something that F# does amazingly or something
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:29
Functional code is great for data transformations
Steven Kirk
@grokys
Dec 26 2015 17:29
yeah, i get it!
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:29
I mean, what's the point of IGeometry in your example above? Makes more sense to use composable render operations, which suggests functions
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:29
You don't depend on state, you get wings of freedom this way
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:30
You get other benefits, too
Steven Kirk
@grokys
Dec 26 2015 17:30
well IGeometry would probably be a D2D Geometry or something
platform-dependent
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:30
And then here comes text
and images
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:30
Easier to reason about, easier to have correctness, etc
Steven Kirk
@grokys
Dec 26 2015 17:31
yeah, well text and images are a form of geometry
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:31
Well, in my mind, that's more of a unit -> bool than state
You don't need an object tree to represent drawing
Esp. Since it probably is an interface with one method anyways
Steven Kirk
@grokys
Dec 26 2015 17:33
it'd also be used for hit testing
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:33
Hit testing is a UI-thread concept
You don't need it in your perfect render-thread world
BTW, control is actually represented by it's transformation, clipping region, opacity and the list of render commands
Steven Kirk
@grokys
Dec 26 2015 17:34
yep, i did say "for the sake of simplicity"
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:34
That's everything that render thread needs to know about
Steven Kirk
@grokys
Dec 26 2015 17:35
but for hit testing geometry, you either call out to the underlying library or implement all the geometry stuff yourself
d2d/skia/cairo does it better than we ever could
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:35
I'm not sure that underlying library will always be thread-safe
Steven Kirk
@grokys
Dec 26 2015 17:35
not sure either
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:36
I'm not even sure that you can properly implement render thread with cairo at all
Even with skia it will be tricky
Steven Kirk
@grokys
Dec 26 2015 17:36
how so?
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:36
On mobile devices you need to pass your render results to OS
And you need to do that on UI thread
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:37
Well, most subsystems will require a render thread... but you could easily abstract over that
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:37
You also need to properly react to WM_PAINT on windows
Steven Kirk
@grokys
Dec 26 2015 17:37
well at the moment we always render on UI thread, but if we had threaded rendering that could trivially be made configurable
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:38
The application framework could spin up two threads... the ui thread can be completely internal and hidden from user
+
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:39
And then we'll run into interop issues
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:40
If you want to support interop, it'd be tricky
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:40
Because on mobile devices OS calls your code from actual UI thread
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:40
That's not a big deal
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:40
It is
You are also supposed to call certain OS stuff only from actual UI thread
created and managed by OS
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:41
That's manageable though. Tricky part would be if you wanted to support something like hwndhost
Yeah, you'd need api to support that... not tough to do
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:42
We need embedding, you know
Summary: creating a fake UI thread will break a lot of important stuff
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:43
Yeah, embedding/hosting would be trickiest part. But separate thread logic can always be opt in (on by default ) too, if it's too onerous
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:43

separate thread logic can always be opt in

Nope, that's must have feature

Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:43
Not saying create a fake ui thread
Steven Kirk
@grokys
Dec 26 2015 17:44
yeah, i think to support even e.g. games on PC, thready rendering would need to be disabled
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:44
You can't have mobile UI framework that renders and composes everything in UI thread
BTW, read about CoreAnimation
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:44
Saying create a separate logic thread. Do whatever you need for rendering
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:44
iOS has separate thread rendering done right
Actual control rendering happens in UI thread
Then layers are sent to composer thread
That applies transformations, effects and do compositing
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:46
I'm saying... use 1+ threads for os support, but separate out application logic, and make marshaling core part of api
Because, as you're saying, platforms have their own requirements
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:47
You are sacrificing a lot of critical things for the sake of hack in UI framework
I'd rather use Xamarin.Forms
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:47
Don't see why there's a sacrifice
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:47

Because, as you're saying, platforms have their own requirements

Yep. They all require UI thread to be UI thread, through

Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:49
Yeah, and they all require annoying things when it's time to write your non ui code because of that ;) I'm thinking more on the abstraction level of the user. I don't want to have to think about writing threaded and async code all of the time
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:52
BTW, our current main issue is measuring
rendering has good-enough performance for now
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:53
@grokys regardless of this, would be happy to help you learn f#, and/or look for good places to use it, even if it's not a full immutable render tree
Steven Kirk
@grokys
Dec 26 2015 17:54
:) thanks!
yeah, really interesting to talk about it, even if it seems the ideas a non-starter
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:54
@kekekeks I consider everything required to draw part of rendering, including layout and measurement
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:54
Oh
You can't do measurement and layout on non-UI
because that stuff should be customizable
Steven Kirk
@grokys
Dec 26 2015 17:55
definitely not, unfortunately
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:55
@grokys it's great to reduce boilerplate
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:55
and user implementation might depend on the state
Steven Kirk
@grokys
Dec 26 2015 17:55
measurement is something that really would benefit from immutability, as it could be split among cores
but unfortunately not possible
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:56
You don't need immutability to parallelize stuff
Steven Kirk
@grokys
Dec 26 2015 17:56
no, but it makes it easier
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:56
Not sure I agree, but not sure it's great worth it
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:56
Because your UI thread is the part of the thread pool that does the job
So it's blocked anyway
Steven Kirk
@grokys
Dec 26 2015 17:56
yeah, like i say, it's not possible
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:57
OSG does it, for example ;)
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:57
I'm happy for OSG
But OSG isn't an UI framework
It has different requirements
Steven Kirk
@grokys
Dec 26 2015 17:57
we'd have to completely change our layout system away from our WPF-like one
i'm not even sure what it would look like...
@ReedCopsey where is a good place to learn F#? posted a q to learn-fsharp channel but doesn't seem to be much activity
like, somewhere for real newbs
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:58
Fsharp beginners slack is good
Nikita Tsukanov
@kekekeks
Dec 26 2015 17:58
Parallelizing measurement and layout isn't a big thing and can be easily done, the problem is that you can't guarantee that some control won't need some state from UI thread
Johan Larsson
@JohanLarsson
Dec 26 2015 17:58
pretty active
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 17:59
If you want real projects to work on, I've got some... happy to work with you
Steven Kirk
@grokys
Dec 26 2015 17:59
ok, great!
@kekekeks fixed the culling issue
your recent asset loader changes have broke some tests though
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:00
Would love to do some more with fsharp.viewmodule, and that'd probably be relevant since it should play great with perspex :)
As an example
Steven Kirk
@grokys
Dec 26 2015 18:01
ok, i will take a look at that!
F# still looks like Russian to me though atm ;)
but i've got a book now
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:01
Look at view model code in fsxaml demos for examples
What book?
if that's not a good one, it's on kindle so i can return it if you have a better suggestion
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:03
I need to read dale's book
Dave too
No idea
Steven Kirk
@grokys
Dec 26 2015 18:03
it seemed about the right level from a quick glance
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:03
But ask me anytime... if your on slack, dm me there, since I get good notifications there
I don't use Gitter much ;)
Steven Kirk
@grokys
Dec 26 2015 18:04
also tried the "F# for C# devs" but it thought i should go for something that doesn't talk about C# so much
Johan Larsson
@JohanLarsson
Dec 26 2015 18:05
browser tabs are free
Steven Kirk
@grokys
Dec 26 2015 18:05
i'll join the slack room
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:05
@JohanLarsson on my phone atmosphere
Arg, atm too
Johan Larsson
@JohanLarsson
Dec 26 2015 18:05
:)
Steven Kirk
@grokys
Dec 26 2015 18:06
hmm, do i need an invite to that slack room?
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:06
Fpchat.com
You'll get one pretty quickly
Steven Kirk
@grokys
Dec 26 2015 18:08
@kekekeks after i merged the resource changes TestApplication doesn't run either
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:09
And yes, biggest part about learning f# is trying not to think in terms of c# ;)
Steven Kirk
@grokys
Dec 26 2015 18:12
yep! i get that from looking at the code!
just need to find a way to link learning f# to perspex so i don't feel like i'm wasting my time
(not "wasting my time learning f#" - more "using my time that i should be spending on perspex")
Johan Larsson
@JohanLarsson
Dec 26 2015 18:13
do you have a job?
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:18
That's why I suggested that library
I can help, and you can use it with perspex
And I'm happy to take contributions ;)
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:24
Btw, is there anything like
In pcl?
Or usable by perspex?
Been thinking about an awesome way to handle vm layer, but need that or something similar that allows runtime definition of props for binding
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 18:51
@grokys any ideas? Or would you be open to a PR if not?
Steven Kirk
@grokys
Dec 26 2015 19:14
hi sorry, been doing family stuff
it doesn't appear that ICustomTypeDescriptor is available to our PCLs
but i think the way to solve that is to get it added to the upcoming .net standard platform rather than rolling our own
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 19:19
@grokys Empty <TabControl></TabControl> takes 4ms to measure, empty <Grid></Grid> 0,0686ms
Empty Expander almost 6ms
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 19:25
<TextBox/> takes first time 15ms to measure
This takes 136ms to measure:
    <StackPanel>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
    </StackPanel>
this takes 0,5ms to measure:
    <StackPanel>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
    </StackPanel>
Reed Copsey, Jr.
@ReedCopsey
Dec 26 2015 19:32
@grokys my understanding is they don't want it there :(
It's very useful for ui, but not much else
Steven Kirk
@grokys
Dec 26 2015 20:21
@wieslawsoltes thanks for that... that's good to know. there should not be such a difference between TextBlock and TextBox
could you maybe try removing the ScrollViewer from the TextBox template?
@ReedCopsey strange... where did you hear that?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:29

@grokys

RectangleControl MeasureOverride 46,4977ms
RectangleControl MeasureOverride 0,0097ms
RectangleControl MeasureOverride 55,1989ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 56,7909ms
RectangleControl MeasureOverride 0,0097ms

without ScrolViewer

Nikita Tsukanov
@kekekeks
Dec 26 2015 20:30

RectangleControl
46,4977ms

Seriously?

measuring rectangle takes 50ms?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:30
no
its my custom UserControl control name
Nikita Tsukanov
@kekekeks
Dec 26 2015 20:31
Which is a rectangle
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:31
This message was deleted
sorry
this:
    <StackPanel>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
    </StackPanel>
but 50ms is withour ScrollViewer in TextBox template
Steven Kirk
@grokys
Dec 26 2015 20:33
ok, so TextBox takes 50ms without ScrollViewer and 136ms with?
both times are bad...
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:33
this is with ScrollViewer included:
RectangleControl MeasureOverride 138,8104ms
RectangleControl MeasureOverride 0,3263ms
RectangleControl MeasureOverride 167,6125ms
RectangleControl MeasureOverride 0,3258ms
RectangleControl MeasureOverride 140,1414ms
RectangleControl MeasureOverride 0,3271ms
Steven Kirk
@grokys
Dec 26 2015 20:34
right yeah, so ScrollViewer is definitely causing problems
Nikita Tsukanov
@kekekeks
Dec 26 2015 20:34
I think that we need to find some scientific paper about layout algorithms
Steven Kirk
@grokys
Dec 26 2015 20:34
thing is, this should be the same algorithm as WPF
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:34
and for reference this is empty UserControl
RectangleControl MeasureOverride 0,0878ms
RectangleControl MeasureOverride 0,0102ms
RectangleControl MeasureOverride 0,0414ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 0,0409ms
RectangleControl MeasureOverride 0,0099ms
Steven Kirk
@grokys
Dec 26 2015 20:35
is that 50ms to measure 10 TextBoxes, or is that per control?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:35
50ms for UserControl with TextBoxes
<UserControl x:Class="Core2D.Perspex.Controls.Shapes.RectangleControl"
             xmlns="https://github.com/perspex"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="clr-namespace:Core2D.Perspex;assembly=Core2D.Perspex"
             xmlns:converters="clr-namespace:Core2D.Perspex.Converters;assembly=Core2D.Perspex"
             xmlns:core="clr-namespace:Core2D;assembly=Core2D"
             Design.DataContext="{Static core:DesignerContext.Rectangle}"
             Design.Width="250" Design.Height="400">
    <StackPanel>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
    </StackPanel>
</UserControl>
Steven Kirk
@grokys
Dec 26 2015 20:36
ok so lets say <5ms per TextBox without ScrollViewer
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:36
using Perspex;
using Perspex.Controls;
using Perspex.Markup.Xaml;

namespace Core2D.Perspex.Controls.Shapes
{
    public class RectangleControl : UserControl
    {
        public RectangleControl()
        {
            this.InitializeComponent();
        }

        private void InitializeComponent()
        {
            PerspexXamlLoader.Load(this);
        }

        protected override Size MeasureOverride(Size availableSize)
        {
            var sw = System.Diagnostics.Stopwatch.StartNew();
            var s = base.MeasureOverride(availableSize);
            sw.Stop();
            System.Diagnostics.Debug.Print("RectangleControl MeasureOverride " + sw.Elapsed.TotalMilliseconds + "ms");
            return s;
        }
    }
}
single TextBox
RectangleControl MeasureOverride 10,5313ms
RectangleControl MeasureOverride 0,0665ms
RectangleControl MeasureOverride 10,4225ms
RectangleControl MeasureOverride 0,0665ms
RectangleControl MeasureOverride 10,6662ms
RectangleControl MeasureOverride 0,0665ms
RectangleControl MeasureOverride 15,9641ms
RectangleControl MeasureOverride 0,066ms
RectangleControl MeasureOverride 16,1277ms
RectangleControl MeasureOverride 0,067ms
Steven Kirk
@grokys
Dec 26 2015 20:37
should really do multiple iterations a for benchmark though
or are the times repeatable?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:37
with ScrollViewer
times are repeatable
and this is on 4,3GHz Core i7
Steven Kirk
@grokys
Dec 26 2015 20:38
that's pretty shocking
should not take 10ms to measure a TextBox
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:39
this is single TextBox without ScrollViewer:
RectangleControl MeasureOverride 4,6653ms
RectangleControl MeasureOverride 0,0097ms
RectangleControl MeasureOverride 8,4021ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 4,3274ms
RectangleControl MeasureOverride 0,0102ms
RectangleControl MeasureOverride 4,173ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 4,3737ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 3,7849ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 4,2419ms
RectangleControl MeasureOverride 0,0102ms
RectangleControl MeasureOverride 3,9326ms
RectangleControl MeasureOverride 0,0099ms
Nikita Tsukanov
@kekekeks
Dec 26 2015 20:39
What does it take to measure a text block?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:39
one moment
single TextBlock
RectangleControl MeasureOverride 0,0632ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 0,0545ms
RectangleControl MeasureOverride 0,0097ms
RectangleControl MeasureOverride 0,0542ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 0,0547ms
RectangleControl MeasureOverride 0,0097ms
RectangleControl MeasureOverride 0,0542ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 0,054ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 0,1062ms
RectangleControl MeasureOverride 0,0125ms
RectangleControl MeasureOverride 0,054ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 0,0604ms
RectangleControl MeasureOverride 0,0097ms
Nikita Tsukanov
@kekekeks
Dec 26 2015 20:40
So it's not the bottleneck, good
Steven Kirk
@grokys
Dec 26 2015 20:41
sounds like something in the measure code is doing something stupid
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:42
this is for 10 TextBlocks with text:
RectangleControl MeasureOverride 0,5742ms
RectangleControl MeasureOverride 0,0099ms
RectangleControl MeasureOverride 0,5286ms
RectangleControl MeasureOverride 0,0092ms
RectangleControl MeasureOverride 0,5619ms
RectangleControl MeasureOverride 0,0104ms
RectangleControl MeasureOverride 0,5429ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 0,6735ms
RectangleControl MeasureOverride 0,0191ms
RectangleControl MeasureOverride 0,5345ms
RectangleControl MeasureOverride 0,0094ms
RectangleControl MeasureOverride 0,5585ms
RectangleControl MeasureOverride 0,0099ms
    <StackPanel>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
        <TextBlock Text="Text"/>
    </StackPanel>
Darnell Williams
@Seeker1437
Dec 26 2015 20:43
weird
every other call its long than the next?
Steven Kirk
@grokys
Dec 26 2015 20:43
i bet it's a linq query
yep
that'll be it
let me go remove all the linq queries from the layout code
@kekekeks are the failing tests hard to fix?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 20:45
and to measure 1000 TextBlocks it takes ~40ms
Steven Kirk
@grokys
Dec 26 2015 20:48
hmm, only Layoutable has LINQ in MeasureOverride and that will usually be overridden
i've removed that - that will actually affect Panel, which is in the template for TextBox
you won't get an updated nuget though until kekekeks fixes the failing tests...
or i can fix them if you're busy?
This message was deleted
This message was deleted
Steven Kirk
@grokys
Dec 26 2015 20:53
This message was deleted
no, ignore that
i think PerspexProperty gets need to be optimized
that will shave a lot off
Steven Kirk
@grokys
Dec 26 2015 21:11
going to create some perf tests and see what i can optimize on the few hours i have left before my vacation
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 21:13
I have found some strange thing with layout
this is way faster:
        <TabControl>
            <TabItem Header="1111">
                <StackPanel>
                    <views:UserControl1/>
                    <views:UserControl1/>
                    <views:UserControl1/>
                </StackPanel>
            </TabItem>
            <TabItem Header="222">
                <views:UserControl1/>
            </TabItem>
        </TabControl>
UserControl1 MeasureOverride 16,3012ms
UserControl1 MeasureOverride 6,8456ms
UserControl1 MeasureOverride 6,8057ms
Steven Kirk
@grokys
Dec 26 2015 21:14
sorry i think you missed something off the URL - faster than what?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 21:14
than this:
UserControl1 MeasureOverride 181,8158ms
UserControl1 MeasureOverride 108,2272ms
UserControl1 MeasureOverride 104,0229ms
UserControl1 MeasureOverride 0,643ms
UserControl1 MeasureOverride 0,6428ms
UserControl1 MeasureOverride 0,6443ms
    <StackPanel>
        <views:UserControl1/>
        <views:UserControl1/>
        <views:UserControl1/>
    </StackPanel>

when I put this UserControl

<UserControl xmlns="https://github.com/perspex">
    <StackPanel>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
        <TextBox/>
    </StackPanel>
</UserControl>

in TabControl and TabItem measure is way faster

The MeasureOverride takes only 16ms vs 180ms when using TabControl/TabItem
Steven Kirk
@grokys
Dec 26 2015 21:18
whaaaat?!?!?
ummmm
wow
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 21:18
But this is only for this example
Nikita Tsukanov
@kekekeks
Dec 26 2015 21:25
I think that tests are failing because there is no entry assembly
When running with xunit
We need to get that "assembly origin" support from OmniXAML
BTW, I'm using ? instead of ;
in resource url
Not sure that it's the right thing to do
Steven Kirk
@grokys
Dec 26 2015 21:33
not sure either...
ok, we can just disable the failing tests until we get the omnixaml support we need
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 21:33

@grokys I am getting some interesting results:
No DataTemplate

<shapes:RectangleControl DataContext="{Binding Path=Project.CurrentContainer.CurrentShape, Mode=TwoWay}"/>
RectangleControl MeasureOverride 2,1329ms
RectangleControl MeasureOverride 0,9551ms
RectangleControl MeasureOverride 0,6228ms
RectangleControl MeasureOverride 0,6312ms
RectangleControl MeasureOverride 0,6085ms

with ContentControl and DataTemplate

<ContentControl Content="{Binding Path=Project.CurrentContainer.CurrentShape, Mode=TwoWay}"/>

       <DataTemplate DataType="core:XRectangle">
            <shapes:RectangleControl/>
        </DataTemplate>
RectangleControl MeasureOverride 85,2919ms
RectangleControl MeasureOverride 0,0675ms
RectangleControl MeasureOverride 84,049ms
RectangleControl MeasureOverride 0,067ms
RectangleControl MeasureOverride 87,7963ms
RectangleControl MeasureOverride 0,0665ms
Steven Kirk
@grokys
Dec 26 2015 21:34
hmm, ok
thanks for this, it's showing where needs optimization
only thing is i'm not sure that now's the right time to be optimizing
is the slowness making it unusable for you?
Wiesław Šoltés
@wieslawsoltes
Dec 26 2015 21:36
well its make it slow but usable, just have wait 300ms :)
When using DataTemplate the MeasureOverride is called twice for shapes:RectangleControl
once it takes 85ms and second time 0,06ms
Steven Kirk
@grokys
Dec 26 2015 21:46
hmm so PerspexProperty getters aren't causing that much slowdown... 0.025ms per get
i was thinking of all the ways they can be optimized, but not sure its necessary
though... that is 1ms every 4 property reads
which could add up pretty quickly
oh no. 1ms every 40
Steven Kirk
@grokys
Dec 26 2015 21:55
worth optimizing at some point, but i'm not sure it's the source of our layout woes
Darnell Williams
@Seeker1437
Dec 26 2015 21:56

Random Note

I am starting to like Perspex more and more as I play with it
I plan to build a app in pure Perspex once I finish helping dan out with docking XD
Steven Kirk
@grokys
Dec 26 2015 21:59
thanks man!
Darnell Williams
@Seeker1437
Dec 26 2015 22:00
No prob! :D
Steven Kirk
@grokys
Dec 26 2015 22:26
@kekekeks fixed the failing tests by putting a null check around assembly in AssemblyDescriptor.ctor
Darnell Williams
@Seeker1437
Dec 26 2015 22:33
@grokys some of the dependancies for Perspex or Perspec.Dexktop aren't uptodate, is it safe to just update all of them?
Steven Kirk
@grokys
Dec 26 2015 22:39
most of them yeah - all except SharpDX to 3.0
as that is a breaking change
might as well do that now
(i'll do it i mean)
Steven Kirk
@grokys
Dec 26 2015 22:48
no i won't
nuget can't manage it
i'll do it when i get back from my holidays
don't want to break stuff just before i go away
why does nuget seem to never quite work?
Darnell Williams
@Seeker1437
Dec 26 2015 22:52
lol idk XD
because you have a real project and it would be too nice to make things easy D:
danwalmsley
@danwalmsley
Dec 26 2015 23:50
@kekekeks whats the latest resource format?
danwalmsley
@danwalmsley
Dec 26 2015 23:58
AvalonStudio.TextEditor.TextEditor.paml
AvalonStudio.TextEditor.TextEditorTheme.paml
these are the resource locations inside another assembly from the main application
inside AvalonStudio.TextEditor
this is the URL im using... but it doesnt work
<StyleInclude Source="resm:AvalonStudio.TextEditor.TextEditor.paml;assembly=AvalonStudio.TextEditor"/>
  <StyleInclude Source="resm:AvalonStudio.TextEditor.Rendering.TextView.paml;assembly=AvalonStudio.TextEditor"/>