Avalonia on Raspbian

[TheColonel2688]

Is Avalonia compatible raspbian yet? I would assume it would be in theory has it would just need to bind to a gtk build that was built for the pi correct? Has this been tested? Or is there work going on in this area?

Sorry if this is the wrong place for this question. I did not know here else to ask.

[kekekeks]

You need to either use Mono as your runtime and our old GTK# backend or somehow obtain an ARM build of libSkiaSharp.

[TheColonel2688]

Is the GTK# back end you speak of no longer maintained?

[snikeguo]

@kekekeks I do not understand why you use GTK? Why not use OPENGL？

[kekekeks]

You need something to create windows to render on, you know

[maitredede]

Hi,
I am also interested in using Avalonia on Raspbian. For rendering backend, OpenGLmay be the preferred rendering engine, since it can render directly to hardware, without X installed. There is also OpenVG that can be used. You can see the available low-level libraries available here and samples here.

There are other things to consider, like handling inputs, to have a fully working solution, but at least, displaying things can be a good start.

[kekekeks]

There is no MIT (or compatible) licensed OpenVG library that meets our requirements. The one that had been shipped with MESA was removed two years ago. And the only reliable and feature-rich library that can render 2D graphics on top of OpenGL is Skia.

Regarding X. /dev/fb0 have been broken for years, so the only way to support proper rendering (i. e. without tearing) is to use DRI/DRM/KMS infrastructure, which was not that stable on Raspberry Pi last time I've checked.

[maitredede]

It is possible to call opengl functions directly, and it works nice. I have also used Qt directly on the raspberry pi without X installed. It uses direct opengl calls also.
I have not found usefull help on how to get Skia running on Raspbian.

[kekekeks]

Ask @mterwoord, he had some success in compiling libSkiaSharp.so for ARM. If you manage to get libSkiaSharp.so binary, you could probably use our /dev/fb0 backend for direct framebuffer access. It also has some initial support for touchscreen/mouse input via libevdev2

[mterwoord]

I had things working with .net core 2.0 and GTK (not sure 2 or 3) and a self-built libskia.

See https://github.com/terwoord/skiasharp-raspberry for a buildscript.

Improvements are welcome. :)

[nicolasr75]

I used @mterwoord 's build script to build a libskia. My Avalonia app contains nothing more than a main window with a grid with two TextBlocks in it. When I try to run it on my Raspberry PI with Raspbian, the main window gets displayed but without any content. When I drag the window around it looks like it crashed. The terminal output does not show any errors though:

Any idea what could be wrong or where I could look for more information to diagnose what went wrong?

[nicolasr75]

After a few more tests with two different Raspberry PIs, I noticed a difference between Raspbian and Linux Mate:

• on Linux Mate my test app seems to work almost fine. The app does not correctly refresh when it was hidden by another window. As soon as my mouse moves over one of the buttons it refreshes though.
• on Linux Raspbian the app starts but no text is drawn at all! The labels are completely missing, the buttons don't show their text. Apart from that the buttons are clickable, so the app is not crashed (as I first had thought)

Any idea why text drawing could fail on Raspbian?

@kekekeks you mentioned /dev/fb0 with libSkiaSharp. Can you tell me what this is about and how I could use it?

(BTW, if anyone is willing to do tests on a Raspberry, I would enjoy to provide one. Remote access via SSH, Teamviewer, XRDP would be possible. I could install either Linux Mate or Raspbian)

[mterwoord]

I'm using yocto to build my own linux distribution, and had issues with a different font to be used.
Maybe that's what's going wrong for you?

[nicolasr75]

@mterwoord You are right. If I set the font of my window explicitly to Courier or the default font of Raspbian (Piboto light) all the text is displayed. I am not Linux expert enough to diagnose this any further so I will stick with this solution for now.

[daniel-lerch]

The next problem on Raspbian is that image scaling does not work like mentioned in #1486 . By setting Stretch="None" I disabled scaling but Avalonia rendered the image correctly.

Maybe someone can investigate this problem. I'm not deep enough in this topic to test a later version of libSkiaSharp than 1.57.1 from May 2017 used in mterwoord's build script.

[LordBenjamin]

• Avalonia 0.7.0
• libSkiaSharp 1.68.0 (compiled as per Build SkiaSharp for Linux Arm mono/SkiaSharp#633 (comment))
• Raspian 9 (stretch)

I can reproduce the issue reported by @nicolasr75 where no text is displayed on Raspian.

I am also seeing incorrect colours - my test app is supposed to display rectangles with green, orange and red backgrounds. This works on Windows, however on Raspian the colours rendered are green, light blue and dark blue.

I use a converter to bind the Border.Background property to my viewmodel:

switch (status) {
    case Status.OK:
        return Brushes.Green;
    case Status.Warning:
        return Brushes.Orange;
    case Status.Failure:
        return Brushes.Red;
    default:
        throw new InvalidOperationException();
}

[kekekeks]

Is there some reliable way to reproduce the issue in QEMU? We hack the hardware to repro, unfortunately.

[LordBenjamin]

I would be happy to try and find the minimum C# / Avalonia repro for these two issues.

I'm not familiar with QEMU though, and from a quick search it seems like getting Raspian running under QEMU is a bit involved (custom kernels etc).

If anyone has a prebuilt environment or scripted setup, that would be much appreciated.

[LordBenjamin]

I was able to resolve @nicolasr75 missing text issue by installing the Microsoft font pack :)

sudo apt-get install ttf-mscorefonts-installer

Looks like the default font in Avalonia is one of the Microsoft ones?

[LordBenjamin]

@kekekeks - @mattleibow mentioned that this is probably due to the Red / Blue channels being swapped. The SkiaSharp GTK widget swaps these channels for BGRA images. https://github.com/mono/SkiaSharp/blob/master/source/SkiaSharp.Views/SkiaSharp.Views.Gtk/SKWidget.cs#L44

I swapped the B/R channels on the brushes in my converter:

        private static readonly SolidColorBrush PiGreen = new SolidColorBrush(new Color(
            Brushes.Green.Color.A,
            Brushes.Green.Color.B,
            Brushes.Green.Color.G,
            Brushes.Green.Color.R));

        private static readonly SolidColorBrush PiOrange = new SolidColorBrush(new Color(
            Brushes.Orange.Color.A,
            Brushes.Orange.Color.B,
            Brushes.Orange.Color.G,
            Brushes.Orange.Color.R));

        private static readonly SolidColorBrush PiRed = new SolidColorBrush(new Color(
            Brushes.Red.Color.A,
            Brushes.Red.Color.B,
            Brushes.Red.Color.G,
            Brushes.Red.Color.R));

        public object Convert(object value, Type targetType, object parameter, CultureInfo culture) {
            Status status = (Status)value;

            switch (status) {
                case Status.OK:
                    return  PiGreen;
                case Status.Warning:
                    return PiOrange;
                case Status.Failure:
                    return PiRed;
                default:
                    throw new InvalidOperationException();
            }
        }

My application works as expected on Raspian with the new brushes (at the expense of Windows compatibility):

Is this perhaps an issue with how Avalonia uses GTK / Skia rather than being specific to the Raspberry Pi?

[kekekeks]

We probably need to somehow detect the pixel format here:
https://github.com/AvaloniaUI/Avalonia/blob/master/src/Gtk/Avalonia.Gtk3/X11Framebuffer.cs#L19
Or play around with XImage flags.

[mattleibow]

If you have a look at what I do with the swapping of the colors for GTK#, I check the platform color format first. You could write a utility function that swaps only on some platforms.

https://github.com/mono/SkiaSharp/blob/master/source/SkiaSharp.Views/SkiaSharp.Views.Gtk/SKWidget.cs#L40

You don't need to che k the actual platform, just the platform color that skia reports.

[kekekeks]

It seems that GTK selects different X11 visual depending on the platform. I think it should be fixed after we switch from GTK to X11 backend. For now we could add pixel format override option to GtkOptions.

[LordBenjamin]

I forced my application to depend on the SkiaSharp 1.68.0 package (overriding Avalonia.Skia's dependency on 1.60.1) and now the R/B channels are consistently wrong on both Windows and Linux using the default brushes.

Raspian:

Windows:

[LordBenjamin]

I rebuilt Avalonia.Skia from source (from the master branch) and that fixes the colours on both Windows and Raspian! I notice that Avalonia.Skia now references SkiaSharp 1.68.0 too.

@kekekeks - do you know if there will be a new set of Avalonia Nuget packages (at least Avalonia.Skia) any time soon?

Edit: Updated all Avalonia DLLs to 0.7.1-build989-beta from the MyGet feed. This works correctly although the window goes black for a few seconds when the application first starts.

[canton7]

Quick summary for those coming in cold (Avalonia 0.8.0):

• Reference the Avalonia.Skia.Linux.Natives NuGet package to get libSkiaSharp
  • You might need Condition="'$(TargetFramework)' == 'netcoreapp2.1'" (adjust your target as necessary) to stop it being included on .net framework builds
• Set the FontFamily of you window explicitly to Courier or the default font of Raspbian (Piboto light), or sudo apt-get install ttf-mscorefonts-installer

The above worked for me, although I haven't tested the image stretching issue.