SkiaSharp Canvas + OpenTK.Core GameWindow

jim_seowjim_seow DEMember ✭✭
edited September 21 in SkiaSharp

Someone recently shares an experimental code testing SkiaSharp canvas drawing using OpenTK.Core GameWindow.

I wonder what could be the advantages of such combination?

Posts

  • mattleibowmattleibow ZAXamarin Team Xamurai

    It may be pretty good. In fact, I am using OpenTK for Windows desktop right now (I haven't gotten the chance to use DirectX just yet). SkiaSharp has basically two modes: raster and GL - each fully supported. Performance will obviously be way better with the GL than raster since we are drawing on the GPU.

    All you need is basically the FBO of some GL context. And that is what he is doing - I think that guy was actually using some of my code - unless we code very similarly.

    I am using OpenTK with the native GL views on iOS, tvOS, macOS, Android, UWP already. Here are the links to the docs that you can have a look at what is there:

    Feel free to use the code that helps. Let me know how things go and if you need any extra APIs.

  • MudMud USMember ✭✭

    @mattleibow said:
    SkiaSharp has basically two modes: raster and GL - each fully supported.

    The GL version is unusable in forms. I assumed that no response to that post mean no known workaround, so it's probably not fair to say it's "fully supported".

  • mattleibowmattleibow ZAXamarin Team Xamurai

    @Mud, I am not sure exactly what you were doing there - I would suggest more information or even a reproducible sample. (That may be why there is no answer, there is nothing to really check)

    I have done a fair bit of testing with SkiaSharp and the GL views and have never noticed this. I may not be doing something that you are, so I will need a test case. The GL bits do work fine (at least for me), you can try out the samples attached to each release. There is a Xamarin.Forms sample that draws an image with both raster and GL - and they are both the same result.

  • MudMud USMember ✭✭
    edited September 24

    @mattleibow said:
    @Mud, I am not sure exactly what you were doing there

    As I said, I simply replaced SKCanvasView with SKGLView, changing nothing else.

    I would suggest more information or even a reproducible sample. I have done a fair bit of testing with SkiaSharp and the GL views and have never noticed this.

    Sorry, a sample didn't seem necessary given how trivial it is to reproduce. You reproduce this from a sample back in May.

    I just now modified that sample to show SKCanvasView and SKGLView next to each other, using the same drawing code. Attached.

    Relevant code:

    MainPage.xaml

            <local:SKGLView     PaintSurface="SKGLView_PaintSurface"     VerticalOptions="FillAndExpand"></local:SKGLView>
            <local:SKCanvasView PaintSurface="SKCanvasView_PaintSurface" VerticalOptions="FillAndExpand"></local:SKCanvasView>
    

    MainPage.xaml.cs

            private void SKGLView_PaintSurface(object sender, SkiaSharp.Views.Forms.SKPaintGLSurfaceEventArgs e)
            {
                Draw(e.Surface.Canvas);
            }
    
            private void SKCanvasView_PaintSurface(object sender, SkiaSharp.Views.Forms.SKPaintSurfaceEventArgs e)
            {
                Draw(e.Surface.Canvas);
            }
    
            private void Draw(SKCanvas canvas)
            {
                canvas.Clear(SkiaSharp.SKColors.White);
                using (var paint = new SKPaint()
                {
                    Color = SKColors.Red,
                    TextSize = 20,
                })
                {
                    canvas.DrawText("Background should be white (255,255,255) and text should be red (255,0,0)",
                        30, 30, paint);
                }
            }
    

    Here's what that produces on the simulator and my phone (OnePlus):


    There is a Xamarin.Forms sample that draws an image with both raster and GL - and they are both the same result.

    Where?

  • jim_seowjim_seow DEMember ✭✭

    @Mud, The GL version is unusable in forms. I assumed that no response to that post mean no known workaround, so it's probably not fair to say it's "fully supported".

    It is great that you share your finding with the community. There could be many reasons to your observation. In both the SKCanvasView and SKGLView, similar drawings were rendered except as you have claimed that the one created by SKGLView seems to be darker than that created by SKCanvasView or alternatively SKCanView seems to be brighter than SKGLView.

    It is an interesting phenomenon! Probably is reported for the first time!

    Both SKCanvasView and SKGLView are indeed "fully supported", you and the community are contributing regularly to identify bugs so we could make both the "fully supported" views more error free.

    The main motivation of me posting this discussion is to get feedback in my view the many facets of potentials in using SkiaSharp, alone (2 in 1 features of having 2D Skia and 3D OpenGL ES) or in combination with OpenTKCore (OpenGL).

    => in other words, when explored correctly, we could perform 2D vector and 3D (OpenGL ES, OpenGL ) -
    Thanks to how @mattleibow makes both SKCanvasView and SKGLView "fully supported" in SkiaSharp,

  • MudMud USMember ✭✭
    edited September 25

    @jim_seow said:
    alternatively SKCanView seems to be brighter than SKGLView.

    SKCanvasView shows the correct color values. SKGLView is 60% darker than it should be, so I think it's clearest to say that SKGLView is darker.

    Probably is reported for the first time!

    It was reported in May.

    As for the semantics of "fully supported", I guess we can agree to disagree on that. My feeling about Xamarin Forms in general is that it's not really supported. It's not just that it's unbelievably buggy, it's that the bugs are in incredibly basic features, reported long ago, and remain unfixed. Most of my time trying to use Forms has been spent finding workarounds for bugs, some of which were reported literally years ago.

    There's no padding on labels, the picker doesn't size to accommodate its items, so on and so forth. There are obviously broken things in the most basic controls. That suggests that nobody at Xamarin/Microsoft actually uses Xamarin themselves.

    For instance, I'm here reporting a bug in SKGLView which is reproduced simply by using it, even once. You literally only have to try it to see this bug. What does that tell you? Nobody at Microsoft actually uses this stuff.

    The most common advice given to people running into the bugs in Forms is to not use Forms. Even the CEO of Xamarin disavowed Forms: "Xamarin.Forms is not Xamarin. [..] we had internally called Xamarin.Forms 'duplo,' to emphasize that it was for childishly-simple apps".

    So what does it mean to say something is "fully supported", if they don't actually uses it and even basic, easy to reproduce bugs are ignored?

    SkiaSharp is really the only thing that saved my app. I gave up on using Xamarin Forms to create the UI and I now draw it entirely from scratch using SkiaSharp. Would be nice if I could use the GPU accelerated version, but it's still better than nothing, a sentiment that's true of Xamarin itself. I would be nice if Forms was really supported, but what I'm doing now is still better than writing two versions of my app and being able to use C# and the .Net library is huge.

  • mattleibowmattleibow ZAXamarin Team Xamurai

    @Mud, I have a solution to the issue you are seeing - it is just an issue with the styles. See my comment: https://github.com/mono/SkiaSharp/issues/299#issuecomment-331990904

    I just want to mention the issue of "fully supported". Both SkiaSharp and Xamarin.Forms are fully supported by Xamarin/Microsoft. Each project has a team working to fix bugs, add features and anything else that needs doing.

    Just this week in Xamarin.Forms, there has been over 70 commits, 2K line changes, 9 merged PRs and there has also been a release. We are also working to add GTK# and WPF support for Xamarin.Forms. In SkiaSharp, there have been a few bug fixes and I am commenting on this post (which is support since this I am the lead developer on this project). I am also going to be releasing an update soon.

    What may be causing an issue is the definition of the word "support". I work for Xamarin, and I am supporting you (hopefully) - thus Xamarin is supporting the product. It is by no means bug-free and nothing really is. It may also not be fully featured, but then again, what truly is? Xamarin.Forms and SkiaSharp has many features (and sadly a few bugs), but we are working (with the open-source community) to not only fix bugs, but to add new features.

    And that quote, I would like to quell any fears. (just noting that that post was 2.5 years ago, and things have been changing I believe Xamarin is behind Xamarin.Forms fully (see the ongoing work and the new platforms), and I think there may have been a misunderstanding of the meaning of the quote. Nat was saying that "Xamarin.Forms is not Xamarin", this is the same as if Google had said "The YouTube web API is not Google", or Apple saying "ResearchKit is not Apple". The product is rather a part of the larger offering.

    In the case of Xamarin.Forms, one product (Forms) is based on the platform (Xamarin). Xamarin is much more that just Xamarin.Forms. There is Xamarin.Android, Xamarin.iOS and Xamarin.Mac (and much more).

    I hope this fixes your issue, and also helps to show that we at Xamarin and Microsoft are all for supporting developers, on any platform. We want you to succeed and we really do appreciate any feedback. This issue that you are reporting is actually a good example. Although not a bug with Xamarin.Forms or SkiaSharp, it shows that there may be a bug with Google's part in Android - or maybe our documentation is incorrect.

    This is not me saying that if there is a bug, you fix it, but if you do find a bug with Xamarin.Forms you can either report it here and we will try our hardest to fix it as soon as possible, or you can see if you can fix it here.

    Please continue providing feedback, we try our hardest to offer the best product, but you can help by pointing out our faults.

  • MudMud USMember ✭✭

    @mattleibow

    Great job finding the issue. And apologize for my venting session. Your points are well taken.

Sign In or Register to comment.