GPU Skia Support

[danwalmsley]

Credit to @MarchingCube and @nc4rrillo who originally did a lot of this work.

This template is not intended to be prescriptive, but to help us review pull requests it would be useful if you included as much of the following information as possible:

• What does the pull request do?
  allows for gpu rendering on skia.

[jkoritzinsky]

This project doesn't exist in this PR. Can we revert the change to this file?

[danwalmsley]

fixed

[jmacato]

Hmm, trying this out on linux, it doesnt seem to be accelerating stuff. Try out RenderDemo maximized and switch between Tab items. It'll be locked to 29fps and it'll look a bit stuttery.

Edit: Seems to be CPU utilization is less (+/- 2%). Screen tearing is apparent on maximized mode

[danwalmsley]

Its not implemented on linux backend, its only the apis needed to build it

[Gillibald]

I am not a friend of the Avalonia.GPU naming. This isn't an independent solution. This is very specific to Skia. In my opinion IGpuContext is some surface that can be used to construct a GRContext. What else can you use this for?

[danwalmsley]

@Gillibald my impression was that
https://github.com/AvaloniaUI/Avalonia/blob/8efc1df0a3af785ae384911b13452844eaf8c314/src/Avalonia.Gpu/IGpuContext.cs

was resusable across platforms?

@nc4rrillo would know better, but we could move this interface to the skia backend until it was determined if it could be used else where

[ncarrillo]

I don’t understand what about IGpuContext ties this to Skia? GrContext really just needs some way to resolve function pointers for its internal GL calls.

Other implementations which have OpenGL implementations would need similar functionality.

Moving this into Skia would needlessly tie the Windowing impls to Skia.

[Gillibald]

Then it is an OpenGLSurface and tied to that implementation. How would you use that with other graphics API's? Can you give us more insides how IGPUContext is used?

Shouldn't we extract the more common used methods out of the ICPUContext(Surface) into for example ISurface? Btw should a resized handled that way? Shouldn't this the other way round? A resized event would make more sense. That decouples the resize from the underlying windowing system.

[ncarrillo]

So if you’re using a non GL context then you could probably no op the functions which don’t apply like loading function pointers. That’s a reasonable trade off to me.

For DirectX, I’d much prefer us go through ANGLE and have a consistent abstraction given that they’re the odd man out API wise.

If someone needs the underlying device ANGLE has ways to do that.

With regards to resizing, when the viewport changes we need to notify the context in addition to recreating the surface. Unless I’m not understanding your point. Maybe some pseudo code mocking up how you think the interface should be could help?

To your last point about potentially making this a super interface with common stuff from ISurface, I think it could work, we’d just need to bike shed on the design a bit.

[Gillibald]

interface ISurface
{
    Size Size { get; }
    Dpi Dpi { get; }
    void Resize(Size size, Dpi dpi)
    void Present();
} 

Present is optional and is only needed if you need to copy some state. So not sure if this should be in the base interface or in IFramebufferSurface Surface. FramebufferRenderTarget should call it by default.

There could be a IFramebufferSurface, IGlSurface etc.

I like the idea using ANGLE to render stuff but we would need our own text rendering (Typography has support for OpenGL ES) etc.

Sry for the frequent editing

[kekekeks]

I don't think that it's really compatible with non-OSX (especially GLX). It also doesn't seem to contain support for multiple OpenGL contexts with shared resources which is needed for multithreaded environment. It also expects a prepared OpenGL context to always exist in Window's surfaces which isn't a good API design.

I'll take a shot at implementing GPU rendering with Win32/GTK + Skia backend combinations and see what can be done here.

[danwalmsley]

I don't think that it's really compatible with non-OSX (especially GLX). It also doesn't seem to contain support for multiple OpenGL contexts with shared resources which is needed for multithreaded environment. It also expects a prepared OpenGL context to always exist in Window's surfaces which isn't a good API design.

I'll take a shot at implementing GPU rendering with Win32/GTK + Skia backend combinations and see what can be done here.

I will close this PR for now 👍