I tried giving it a try catch: ``` [DOTNET] Failed loading _glDrawBuffer: undefined symbol: __glDraw
I tried giving it a try catch:
HOk nevermind about that, I used another way for the GL context
Hbut it crashes when I rotate the screen
H
Lyeah it definitely seems like its wanting to create a GL context but you are on GLES
Li get the same problem, but i assumed it was my code
Li guess not
HHere is without skia, just gl.Clear
HI wonder why
Window Size and Device Size is differentHMoreover they arent swapped number positions or anything, just random
HSo I think
Window Size doesn't rotate or change at all, which it should be changing, while the Device Size does rotateHThis is found right after the screen rotates
[SDL] SDLActivity thread ends (error=Try to release egl_surface with context probably still active)H@kaijellinghaus do you know any workaround for it?
EI'm curious why examples are using unsafe code. Is it necessary since I've never worked with unsafe code?
RTechnically there are overloads that are safe
RHowever the return values might not be safe
Fif youre gonna use any of the apis silk has you will need to do unsafe whether you like it or not sooner or later
Lyou can think of it like a C style ptr
RReally there is just no way around it
Ryou might as well just use the pointers anyway because you are often with return values going to be getting either a struct that contains pointers or a pointer itself
Khopefully we can make most things safe in 3.0 
Ridealy
EPerformance aside, isn't there always a safe/managed counterpart to unsafe concepts?
Kyes**
Rnot ALWAYS
Rbut most of the time
Kthere is always some kind of safe concept
EThe way I'm trying to approach thing is to make a safe layer in the backend of the C# side so the user code still uses managed code.
Kbut sometimes the cost associated with that replacement is too great
ELike, even struct pointers can probably be classes, even though there might be a performance impact.
EWell, yeah, I'm not too savvy about the costs and stuff.
Kexactly, but the marshalling back and forth is not necessarily something we want to do for return types
Kfor overloads it's fine, as you choose what to put in
Kbut the return type you can't choose
Kso we really want near zero-cost abstractions always
EI see. Has anyone done some benchmarking of this?
KIf you have a good baseline to suggest, I'd be happy to do so
EI don't think I'd be able to find this on the web myself. Lack of a way to phrase it.
Kbut the overall feedback has been that people porting their apps to Silk have seen some performance benefit
Rthat is a good thing
Kit's very hard to benchmark, as most libs either don't provide the good overloading we do, so a comparison is unecessary, or they have them and don't care for performance so a comparison makes no sense
EOh, I just meant comparing in general. Doesn't have to be tied to a specific library. Like a unit test for performance, I guess.
Li mean it's easy to beat monogame spritebatch lol
EThat'd just be oriented around unsafe features and how C#/.NET affects their speed.
KYeah the comparison with ourselfs is interesting for sure
L(1kfps -> 3 sometimes 4k fps when i moved type silk)
EI'm not sure I have seen much if any improvement to the interop side of .NET lately, but they definitely seem to have a focus on improving performance since .NET 5.
Ai could try some performance comparisons, since i ported mine recently the opentk implementation of my engine is still relatively up to date.
not too much i could test though, i guess just some model rendering performance and the sprite batching performance averages
not too much i could test though, i guess just some model rendering performance and the sprite batching performance averages
MI am trying to use Silk.Net.OpenCL from LinqPad 5 (which targets .NET Framework), so I assume it's pulling in the NetStandard2.0 version. It seems to work fine for the GetPlatformIDs and GetPlatformInfo calls, but hangs when it gets to the GetDeviceIDs call. Any thoughts on why it's hanging?
Ndoes GLFW work with macos?
Nive been getting strange errors on window surface creation lately
