[BUG] Protected Memory Access Attemps on GPU GRContext

[axel578]

Description:

I have an application with an SkElement in WPF, I Made a GPU GrContext, and everything works, but at random times the error: System.AccessViolationException happears when any attempt to drawing on the Surface canvas binded with the gr context is made. The error was triggered when the InvalidateVisual() was called on the SKElement from a background worker, if I don't use the background worker, everything goes fine. < Maybe dued to the memory used like montains in the TaskManager
Code

var vb = new WpfGles.GlesImage(); //Set The GrContext
            vb.Width = 1920;
            vb.Height = 1080;
            vb.start();
            interf = GRGlInterface.Create();
            _context = GRContext.CreateGl(interf);
            //_context.SetResourceCacheLimits(200, 4000000000);
            _context.SetResourceCacheLimit(4000000000);
            var glInfo = new GRGlFramebufferInfo(
                fboId: 0,
                format: SKColorType.Rgba8888.ToGlSizedFormat());

            var renderTarget = new GRBackendRenderTarget(
                width: 1920,
                height: 1080,
                sampleCount: 0,
                stencilBits: 0,
                glInfo: glInfo
                );
            

            Surface = SKSurface.Create(
                _context, renderTarget, GRSurfaceOrigin.BottomLeft, SKColorType.Rgba8888);

Expected Behavior

Surface.Canvas.Draw(...) without any System.AccessViolationException

Actual Behavior

at SkiaSharp.SkiaApi.sk_canvas_draw_image(IntPtr param0, IntPtr param1, Single x, Single y, IntPtr param4)
at SkiaSharp.SKCanvas.DrawImage(SKImage image, SKPoint p, SKPaint paint)
at sdg.VideoConceptor.Scene_PaintSurface(Object sender, SKPaintSurfaceEventArgs e) in C:\Users\axel\source\repos\sdg\sdg\VideoConceptor.xaml.cs:line 524
at SkiaSharp.Views.WPF.SKElement.OnRender(DrawingContext drawingContext)
at System.Windows.UIElement.Arrange(Rect finalRect)
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.ContextLayoutManager.UpdateLayoutCallback(Object arg)
at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at sdg.App.Main()

Basic Information

• Version with issue: 2.80.2-preview.36
• Last known good version: None
• IDE: Visual Studio 2019

Screenshots

[mattleibow]

It might be because you are drawing on the surface using a different thread that you created the buffer?

I am not exactly sure how GL works, but I don't think you can create and use a FBO from different threads? Or, you may be conflicting with multiple calls and such. Finally, is the GLES context set to be the current?

Are you able to replace all the drawing code and say clear with red? Does that crash?
You can also try using the same background thread to create and draw, that might show where the issue is happening.

Finally, are you able to provide a small repro case?

[axel578]

Yeah, seems it's that, Is there any way to give access to drawing on the SkElement directly rather than doing it through the event Scene_PaintSurface ?
Is there also any way to implement A GrContext from open gl 64 bits and not 32bits or something different from open gl ? because skiasharp works really well with gpu

[mattleibow]

I am assuming you are using https://github.com/l3m/wpf-gles?

That code doesn't seem to be 32/64 bit specific. It might just be the binaries or target you are compiling?

For UWP I actually "cheat" a bit and don't actually follow the same pattern. I have a render thread that runs and when the view is "invalidated" a simple raise an event from the background thread.

Also, that Gles is a view... Can you not use that directly? Basically create your own "paint" event? Effectively, create a new control that inherits from GlesImage and then creates and draws via a internal renderer? The you don't need an SKElement at all.

[axel578]

Okay I'll give a try on that, I used the SkElement because it's the fastest way to render from my test, thanks again for your answer

[mattleibow]

Let me know how it goes.

SKElement is not the most exciting things, but it will always come back to the UI thread - which may not be what you want: https://github.com/mono/SkiaSharp/blob/master/source/SkiaSharp.Views/SkiaSharp.Views.WPF/SKElement.cs

If you get nice working example of GLES and SkiaSharp, then I'll have a look at merging it into this repo so you won't have to maintain it. If you are interested in that sort of thing 😄

[mattleibow]

There is also the #1521 PR which has some things that is related to this one. And #745