These are chat archives for AvaloniaUI/Avalonia

26th
Nov 2015
Darnell Williams
@Seeker1437
Nov 26 2015 01:34
Hey guys
Enjoying the night so far?
Nikita Tsukanov
@kekekeks
Nov 26 2015 01:35
Night? What's that?
My sleeping cycle is a mess (
Darnell Williams
@Seeker1437
Nov 26 2015 01:36
haha XD
$5
yay
Darnell Williams
@Seeker1437
Nov 26 2015 15:46
...
lol....
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:09
Well, I've fixed the double comparison (#331) and also posted an issue to the Roslyn bugtracker: dotnet/roslyn#7088
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:14
double DoubleEpsilon = Math.Pow(2, -DoublePresision);
Why not just use hardcoded values for every supported platform?
Darnell Williams
@Seeker1437
Nov 26 2015 16:14
Isn't that bad though?
I think it would pose a problem in edge cases to do that
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:15
BTW, why do we even support situation when maximum ~= minimum?
Darnell Williams
@Seeker1437
Nov 26 2015 16:16
Why not?
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:17
@kekekeks I don't know the values for every platform and even don't have a list of these platforms :)
There's some ARM trickery, are you sure we want to do something with it?
I'm okay with hardcoding it as 1.11e-16 or something like that.
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:25

There's some ARM trickery, are you sure we want to do something with it?

Do ARM processor have different machine epsilons?

Or is it architecture-specific?
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:26
I am not sure about that, but they definitely have different Double.Epsilon. I have not enough experience to say whether the machine epsilons are different.
(you could check MSDN about that: it says that Double.Epsilon is zero for ARM)
I think the cause is absence of denormalized numbers, but what the hell.
@kekekeks well I thought about that a bit, and I think that it's impossible to have a significantly different result of 2^-53 even on ARM without denormalized numbers. I think we could set it to 1.11022302462516E-16 constant. Will it be more appropriate?
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:33
$ echo '#include <float.h>'|cpp -dM - |grep DBL_EPSILON|grep double
#define __DBL_EPSILON__ ((double)2.22044604925031308085e-16L)
amd64
This message was deleted
$ echo '#include <float.h>'|./arm-linux-androideabi-cpp -dM - |grep DBL_EPSILON|grep double
#define __DBL_EPSILON__ ((double)2.2204460492503131e-16L)
armv7
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:35
Hm that's interesting. It's about 2 times different from the number defined by Math.NET.
Well I have no objections to use the armv7 number.
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:36
echo '#include <float.h>' | arm64-r10e-21/bin/aarch64-linux-android-cpp -dM - |grep DBL_EPSILON|grep double
#define __DBL_EPSILON__ ((double)2.22044604925031308084726333618164062e-16L)
arm64
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:37
It they really have no denormalized numbers, then we should take the max of these three (because anything less that epsilon could be coerced to 0).
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:37
$ echo '#include <float.h>' | mips-r10e-14/bin/mipsel-linux-android-c++ -dM -E - |grep DBL_EPSILON|grep double
#define __DBL_EPSILON__ ((double)2.2204460492503131e-16L)
mips
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:37
I think it'll be okay for our purposes.
Also the two time difference with my value could be explained by Wikipedia: https://en.wikipedia.org/wiki/Machine_epsilon
There are two ways of calculating the epsilons, and I've used the first one (as Math.NET), but the language standards seem to prefer the second.
Friedrich von Never
@ForNeVeR
Nov 26 2015 16:54
I've updated the PR with armv7 / mips value.
Nikita Tsukanov
@kekekeks
Nov 26 2015 16:54
I'm not sure which one we should use
But arm one is larger, so it should cover more cases
Steven Kirk
@grokys
Nov 26 2015 17:12
@ForNeVeR could you go back a bit and explain why this is necessary? what is the current problem with ProgressBar that this will solve?
Nikita Tsukanov
@kekekeks
Nov 26 2015 18:44
DivideByZeroException, I guess
or somethinh like that
Nikita Tsukanov
@kekekeks
Nov 26 2015 19:44
@grokys For designer support to be implemented in perspex itself I need something that can reference Perspex.Markup.Xaml
I was initially planning to do that in Perspex.Application, but Perspex.Markup.Xaml wants IAssetLoader from it
So we either move IAssetLoader somewhere else
or I'll need a separate assembly
I think that IAssetLoader can live in Perspex.Base
Darnell Williams
@Seeker1437
Nov 26 2015 20:04
Hmmmm
I actuallythinkt hat would be a good idea (put it in Perspex.Base)
Steven Kirk
@grokys
Nov 26 2015 20:56
Yeah ii wouldn't mind that
@grokys Perspex/Perspex#332
I've replaced IWindowImpl/IPopupImpl registrations with IWindowingPlatform
Darnell Williams
@Seeker1437
Nov 26 2015 21:07
hmmmm
Steven Kirk
@grokys
Nov 26 2015 21:08
Ok, not at home at the moment, will check in the morning
Darnell Williams
@Seeker1437
Nov 26 2015 21:08
wait does that affect mobile?
Nikita Tsukanov
@kekekeks
Nov 26 2015 21:08
I've reused our scaling infrastructure from mobile, yes
Steven Kirk
@grokys
Nov 26 2015 21:08
I'd you could add your reasoning to the pr it would be appreciated, to help me understand
Excellent that you've got scaling in there too!
Will that also help us with dpi scaling?
Nikita Tsukanov
@kekekeks
Nov 26 2015 21:10
I've reused existing DPI scaling infrastructure
Darnell Williams
@Seeker1437
Nov 26 2015 21:10
It should technically.
Nikita Tsukanov
@kekekeks
Nov 26 2015 21:10
That we are already using for mobile
It only supports scaling factors of the power of two
Because SnapToPixel handling is ignorant of scaling
So for now it's only suitable for mobile and designer
Darnell Williams
@Seeker1437
Nov 26 2015 21:11
That is acceptable, but I would love to have the option to do other scaling too
Nikita Tsukanov
@kekekeks
Nov 26 2015 21:16
That may overcompicate things
Like finding a widget under cursor
For now scaling layer exists between ITopLevelImpl and TopLevel itself
That's where we transform coordinates
Render transform is easy, because all it needs is PushPreTransform+PushTransformContainer before rendering is done