Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SkiaSharp restores OpenTK libraries not compatible with net 5.0 #1803

Closed
vbaros opened this issue Sep 9, 2021 · 22 comments · Fixed by #2989
Closed

SkiaSharp restores OpenTK libraries not compatible with net 5.0 #1803

vbaros opened this issue Sep 9, 2021 · 22 comments · Fixed by #2989

Comments

@vbaros
Copy link

vbaros commented Sep 9, 2021

I'm using SkiaSharp on Windows. My project is targeting net5.0. When I restore SkiaSharp nuget package this is the warning I get:

Warning NU1701: Package 'OpenTK 3.1.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net5.0-windows7.0'. This package may not be fully compatible with your project.

Warning NU1701: Package 'OpenTK.GLControl 3.1.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net5.0-windows7.0'. This package may not be fully compatible with your project.

I know OpenTK library is already updated to work with net 5.0 but I do not see OpenTK.GLControl being updated any more.
The question is if we OpenTK.GLControl can be removed from SkiaSharp or replaced with some other control? Also can OpenTK dependency be updated to newer version targeting net 5.0? I know I can do that directly in my project but it would be nice to have that directly from the nuget package.
@Gnimuc
Copy link

Gnimuc commented Oct 21, 2021

You need to install GLWpfControl v4.1.0:

Install-Package OpenTK.GLWpfControl -Version 4.1.0

You may also need to downgrade OpenTK to [4.3, 4.4].

@NogginBops
Copy link

NogginBops commented Oct 27, 2021 •
edited
Loading

There actually is an updated version of GLControl. You can find it here:
https://www.nuget.org/packages/OpenTK.WinForms/4.0.0-pre.6
https://github.com/opentk/GLControl

It's a "prerelease" but it's been stable since we released it so you can think of it like a release candidate.

@Gnimuc
Copy link

Gnimuc commented Oct 28, 2021 via email

@NogginBops
Copy link

If you are looking for a Wpf control GLWpfControl is the best option. I think that GLControl will have the airspace issue when used in a WindowsFormsHost. But I'm not sure.

@dbowser
Copy link

dbowser commented Jan 10, 2022

There actually is an updated version of GLControl. You can find it here: https://www.nuget.org/packages/OpenTK.WinForms/4.0.0-pre.6 https://github.com/opentk/GLControl

It's a "prerelease" but it's been stable since we released it so you can think of it like a release candidate.

I have included that package but still get the warning...
How can I prevent that from appearing?

@jeremy-visionaid
Copy link
Contributor

@mattleibow This is a bigger problem for SkiaSharp.Views.WindowsForms 3.0.0-preview.x since previously SkiaSharp could be used in a WinForms app by referencing SkiaSharp.Views.Desktop.Common. But the Extensions have now been moved to SkiaSharp.Views.WindowsForms, which leads to NU1701 if attempting to use it (it resolves to net462 rather than net7.0-windows10.0.19041).

@andersforsgren
Copy link

andersforsgren commented Aug 5, 2024 •
edited
Loading

@dbowser Did you ever find a solution to this?

I'm facing the same issue, is there a workaround for this now several years later?
SkiaSharp.Views.WindowsForms for net8.0 has a dependency on OpenTK.GlControl for net4X which doesn't work.
Is this expected? It happens both with 2.88.0 and 3.0.0-preview.

@jeremy-visionaid
Copy link
Contributor

@andersforsgren I use SkiaSharp.Views.Desktop.Common (which doesn't bring in OpenTK) and then wrote my own custom control using OpenTK.Graphics. It's not a lot of code to roll your own, but the OpenTK bindings leave a lot to be desired (esp. with ANGLE).

@NogginBops
Copy link

@jeremy-visionaid what about the OpenTK bindings are lacking?

@jeremy-visionaid
Copy link
Contributor

jeremy-visionaid commented Aug 5, 2024 •
edited
Loading

@NogginBops Oh dear. I didn't spot you on the chain here. Now I feel bad for being harsh. I'm grateful that I was able to build upon your work which made all this stuff possible to begin with. So, please accept my apologies.

I'd thought about opening a PR to address some of the stuff but it would have broken/altered the public API for OpenTK, so I just redefined some stuff internally to make things easier and ship on time. So, some things that I would have in OpenTK that would have helped with my task:

Firstly, IIRC some of the constant names that are defined don't match the upstream definitions. I don't recall exactly which ones they were, but I recall it making it hard to write against the extensions because of discrepancies.

Secondly, not all the required constants are defined. I'm happy to paste some of them here, but it's not exhaustive (unless I've missed something, stuff like EGL_NO_CONTEXT etc. are also not present):

    const int PLATFORM_ANGLE_DEVICE_TYPE_NULL_ANGLE = 0x345E;
    const int PLATFORM_ANGLE_DEBUG_LAYERS_ENABLED_ANGLE = 0x3451;
    const int EXPERIMENTAL_PRESENT_PATH_ANGLE = 0x33A4;
    const int EXPERIMENTAL_PRESENT_PATH_FAST_ANGLE = 0x33A9;
    const int EXPERIMENTAL_PRESENT_PATH_COPY_ANGLE = 0x33AA;

Lastly, the app I'm working on aims to be high performance and low latency, so I'd prefer bindings that accept spans instead of arrays. Not exactly a problem for EGL I know, but with netstandard2.1 and later I'd think that would be the most favourable signature to work against.

@dbowser
Copy link

dbowser commented Aug 5, 2024

@dbowser Did you ever find a solution to this?

No, sadly we gave up and used a commercial library instead. After not seeing this addressed, we didn't have the confidence to use the package.

@NogginBops
Copy link

NogginBops commented Aug 5, 2024 •
edited
Loading

@jeremy-visionaid It's fine being harsh, getting feedback is important and often the most important feedback never gets where it needs to. If you have time it would be great if you could open an issue or two about what you would like to see be different. Even if it can't be solved in OpenTK 4 (which it very well might be) we could make sure we have things fixed for OpenTK 5.

I have recently been using the OpenTK EGL bindings in combination with ANGLE for the new OpenTK 5 platform support and while doing that work I've also noted that some of the constants are missing. I've created a PR with the fixes I had in my working branch #1732, would be really appreciated if you could comment the list of missing constants that you found so I could add them. :)

As for spans, it would be totally reasonable to add span overloads to the EGL functions, if you could open an issue about this so I can remember to do it. As for the OpenTK 4 OpenGL bindings it's quite a bit more work to make that happen. OpenTK 5 has a new bindings generator which generate span overloads, so that is something atleast.

@jeremy-visionaid
Copy link
Contributor

@NogginBops Thats, awesome, thanks for being so responsive. I'd happily look to port to the preview and try and get some feedback/PRs on it if there are problems so I can remove the extra bits from my project. 👍

@dbowser I'm sorry to hear that you had to target something else. I've generally found SkiaSharp to be really good, but admitedly there can be a bit of manual effort to get things off the ground for hardware acceleration for instance. I'd love to see the Direct3D back-end finished off and merged (#2817), then I wouldn't even need OpenGL.

@NogginBops
Copy link

@jeremy-visionaid I created this PR from this discussion opentk/opentk#1732 but I think I forgot to link or tag you in the issue, so if you are still able to produce a list of missing constants that would be fantastic!

@jeremy-visionaid
Copy link
Contributor

@NogginBops I'm sorry I've been too bogged down in other urgent work to get to look at OpenTK 5 yet, but I'll certainly take a look at the PR and comment there. Thanks again!

@mattleibow
Copy link
Contributor

I am not sure what the best solution is here since there is no stable opentk GL control for winforms.

The nuget warning is just a warning and I think if you explicitly reference it and add a nowarn to the package reference then it may just keep working.

An alternative is for us to move to 4.x, but we probably will need a stable version of those packages. Is there any technical reason why it is not stable? Or is it more that there is no active development on it?

For wpf we merged a PR to move the net7+ things to the 4.x series because we got a stable version. If this is really something that people need for net8 and the warning is super bad for some reason, then maybe getting the GL control stable and in a state where those maintainers are comfortable releasing is the next step here?

I think the 3.x series works, but a warning is not ideal and it is not maintained much I think?

@mattleibow
Copy link
Contributor

A stable skia nuget depending on a prerelease nuget may be totally fine, but it may scare some companies more that a warning which they may just be ignoring...

We could potentially keep netfx on 3 and move net7+ to 4 and live with the fact that scared enterprises will still be on netfx and never know but the young and hip netcore-ers are always on the edge. But, I will need to talk to people. If I was independent, then I could do it, but I got managers and scared enterprises who know those managers :)

@mattleibow
Copy link
Contributor

mattleibow commented Sep 3, 2024 •
edited
Loading

@NogginBops is there a reason the stable preview is not a stable nuget? If you are thinking that it is good and nothing terrible has happened, would be some way to go stable in the near-ish future?

We could start the process today and make preview 3.x skia depend on preview 4.x winforms. I want to release stable in time for .net conf, but I got a baby coming this months so who knows. I will try to get stable, but maybe it will be in the new year once all the celebrations stop and then we can start the new year with stable.

We shall see, but if opentk is open to going stable in the next 6 months or so then I think this could be a plan?

@NogginBops
Copy link

@NogginBops is there a reason the stable preview is not a stable nuget? If you are thinking that it is good and nothing terrible has happened, would be some way to go stable in the near-ish future?

I've been meaning to release a release version of the package for quite a while, we've not gotten a lot of bug reports about the current prerelease version for the almost a year it's been out.

I'll see if I'm able to release a stable version of the package today. The package will have the same old name OpenTK.GLControl instead of the "new" OpenTK.WinForms package. Should make it easier for everyone to find the new package.

@NogginBops
Copy link

@mattleibow I just released OpenTK.GLControl 4.0.0 https://www.nuget.org/packages/OpenTK.GLControl/4.0.0 (and OpenTK.WinForms 4.0.0-pre.8 which is deprecated and points to OpenTK.GLControl 4.0.0.)

If you have any issues with it please open an issue about it https://github.com/opentk/GLControl/issues/new

@mattleibow
Copy link
Contributor

@NogginBops cool! I'll make a PR to update skia to use the new version on new dotnet.

Thanks.

@mattleibow mattleibow mentioned this issue Sep 4, 2024
Merged
5 tasks
@mattleibow
Copy link
Contributor

Merge the PR and trying to get it out in a preview 5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use the new GLControl packages for WinForms mono/SkiaSharp
7 participants
@vbaros @mattleibow @andersforsgren @dbowser @NogginBops @Gnimuc @jeremy-visionaid