These are chat archives for AvaloniaUI/Avalonia

29th
Jan 2019
mstr2
@mstr2
Jan 29 00:19 UTC
a bugfix is available in PR #2270
jp2masa
@jp2masa
Jan 29 01:34 UTC
no idea why there are properties being registered more than once, but that fix works fine, thanks for fixing this!
mstr2
@mstr2
Jan 29 01:54 UTC
The reason is that AvaloniaProperty.RegisterAttached calls /both/ AvaloniaPropertyRegistry.Register and AvaloniaPropertyRegistry.RegisterAttached. Extending this discussion further: is it an implied contract that AvaloniaPropertyRegistry.RegisterAttached may not be called without a preceding AvaloniaPropertyRegistry.Register call? In this case, the check whether a property is already registered can be removed, and properties only added to the global properties list in the APR.Register method.
Naeron1984
@Naeron1984
Jan 29 13:45 UTC

Guys, I have found a possible bug and want you to confirm that it is indeed a bug.

RenderTargetBitmap.Render uses the visual that was given and if its bounds are in the negative (e.g. it is scrolled) then it will be rendered incorrectly because the renderer logic thinks it is inside of something and clips the excess. However if someone wants to render it to a bitmap - at least i think - their intention is to render the whole thing. Is this by design?

I have an example where I have a Canvas inside of a ScrollViewer and I take a picture of the canvase at the beginning of the scrolling an display that while scrolling to increase performance.

Nikita Tsukanov
@kekekeks
Jan 29 13:58 UTC
Please, create an issue
Naeron1984
@Naeron1984
Jan 29 13:58 UTC
This is my current workaround. (Bounds is protected)
                            var oldBounds = Canvas1.Bounds;
                            ReflectionHelper.SetPropertyValue(Canvas1, "Bounds", oldBounds.Translate(oldBounds.TopLeft * -1));
                            renderTargetBitmap.Render(Canvas1);
                            ReflectionHelper.SetPropertyValue(Canvas1, "Bounds", oldBounds);
Nikita Tsukanov
@kekekeks
Jan 29 13:58 UTC
sounds like a bug
CtrlShiftEscape
@CtrlShiftEscape
Jan 29 17:47 UTC
How to make a window with a border but without a titlebar?
Like WS_POPUP|WS_THICKFRAMEin dwStyle in win32
Nikita Tsukanov
@kekekeks
Jan 29 18:26 UTC
I don't think it's possible with X11
I don't see a border here
That's with MotifDecorations.Border only
Window still has resize grip however
Not sure about OSX
Should be possible, I think
Kermalis
@Kermalis
Jan 29 21:40 UTC
How come I can call IDrawingContextImpl.FillRectangle() and IDrawingContextImpl.DrawImage() fine, but IDrawingContextImpl.DrawLine() throws an invalid operation exception?
Nikita Tsukanov
@kekekeks
Jan 29 21:42 UTC
render-time critical visual?
Kermalis
@Kermalis
Jan 29 21:42 UTC
Nope, still using nightly builds
Nikita Tsukanov
@kekekeks
Jan 29 21:43 UTC
Why are you using IDrawingContextImpl directly?
Kermalis
@Kermalis
Jan 29 21:44 UTC
I'm drawing a healthbar for my game, I find it easier to use it this way instead of have like 40 points with properties
and I'd use a canvas anyway
I need everything pixel-perfect
Nikita Tsukanov
@kekekeks
Jan 29 21:46 UTC
This doesn't answer the question about using IDrawingContextImpl directly
Oh, it's probably RTB
I guess we need to wrap the interface in a proper DrawingContext
Kermalis
@Kermalis
Jan 29 21:48 UTC
Here's what I have:
class WriteableBitmapSurface : IFramebufferPlatformSurface
    {
        WriteableBitmap _bitmap;
        public WriteableBitmapSurface(WriteableBitmap bmp) => _bitmap = bmp;
        public ILockedFramebuffer Lock() => _bitmap.Lock();
    }
...
var wb = new WriteableBitmap(new PixelSize(104, 27), new Vector(96, 96), PixelFormat.Bgra8888);
                using (IRenderTarget rtb = AvaloniaLocator.Current.GetService<IPlatformRenderInterface>().CreateRenderTarget(new[] { new WriteableBitmapSurface(wb) }))
                using (IDrawingContextImpl ctx = rtb.CreateDrawingContext(null))
                {
                    ctx.FillRectangle(Brushes.Aqua, new Rect(0, 0, 104, 27));
...
Nikita Tsukanov
@kekekeks
Jan 29 21:49 UTC
I think you can do the same by overriding Visual.Render
Kermalis
@Kermalis
Jan 29 21:53 UTC
Alright, it doesn't give me the exception when I use one of the "Brushes.x" brushes, only when I use a brush I created in the constructor
Why is that?
Nikita Tsukanov
@kekekeks
Jan 29 21:54 UTC
You haven't shown us the exception, so no idea
Kermalis
@Kermalis
Jan 29 21:54 UTC
It says called from invalid thread when I use my own brushes/pens
mstr2
@mstr2
Jan 29 21:55 UTC
Does anyone know why the Avalonia (Pull Requests) check in #2270 might have failed?
Nikita Tsukanov
@kekekeks
Jan 29 21:55 UTC
Brushes.* return immutable brushes
which are usable from BG thread
BTW, creating drawing context from non-UI thread is discouraged and not supported
Kermalis
@Kermalis
Jan 29 21:56 UTC
Alright, thanks
Nikita Tsukanov
@kekekeks
Jan 29 21:56 UTC
It may and probably will crash in some circumstances
@mstr2 Build has succeded
nuget publish to PR feed was cancelled and that somehow has failed the status check
I'm pretty sure this is invalid usage of the API
mstr2
@mstr2
Jan 29 22:14 UTC
@kekekeks I can't get a reliable test with static initialization, since it happens at an implementation-defined time. The only way to test the "before" and "after" state of registering a property is by controlling the exact time when registration happens.
Steven Kirk
@grokys
Jan 29 22:26 UTC
@mstr2 would it be easier if you just create a new instance of AvaloniaPropertyRegistry and call Register on it with a newd up AvaloniaProperty?
that way you're not relying on side-effects of static members
mstr2
@mstr2
Jan 29 22:29 UTC
@grokys I think that would defeat the purpose of having the test, because then the surface API of AvaloniaProperty.RegisterAttached would not be included in the test.
It's the fact that AvaloniaProperty.RegisterAttached dispatches internal calls to both APR.Register and APR.RegisterAttached that was the cause of the original bug.