Cannot upgrade SkiaSharp to latest "SkiaSharp.SKData"

Julian_Thoms · March 18, 2025, 7:16am

Hi, following a suggestion from you on this forum I have tried upgrading the dependency SkiaSharp to the latest version (3.116.1) as the current version seems to have a bug related to adding a jpeg to a ThinkGeo map.
So my current ThinkGeo Version is 14.2.5 and I have SkiaSharpp, SkiaSharp.NativeAssets.Linux / maxOs / Win32 at 3.116.1

This required me to do an assembly binding redirect as ThinkGeo Core throws an exception otherwise.

	<runtime>
		<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
			<dependentAssembly>
				<assemblyIdentity name="SkiaSharp" publicKeyToken="0738eb9f132ed756" culture="neutral" />
				<bindingRedirect oldVersion="0.0.0.0-3.116.0.0" newVersion="3.116.0.0" />
			</dependentAssembly>
		</assemblyBinding>
	</runtime>

After doing that however, I still cannot start the Map as I get following Error:

Exception thrown: 'System.TypeInitializationException' in SkiaSharp.dll
The type initializer for "SkiaSharp.SKData" threw an exception.
at SkiaSharp.SKData.Create(IntPtr address, Int32 length)
at SkiaSharp.SKBitmap.Decode(ReadOnlySpan`1 buffer) in / <em>/binding/SkiaSharp/SKBitmap.cs:line 573.
at SkiaSharp.SKBitmap.Decode(Byte[] buffer) in /</em> /binding/SkiaSharp/SKBitmap.cs:line 566.
at ThinkGeo.Core.EditInteractiveOverlay.e0U=()
at ThinkGeo.Core.EditInteractiveOverlay..ctor(Boolean designMode)
at ThinkGeo.Core.MapViewBase.HUQ=(Boolean designMode)
at ThinkGeo.Core.MapViewBase..ctor(Boolean designMode)
at ThinkGeo.UI.Wpf.MapView..ctor()

Inner Exception: Unable to load library ‘libSkiaSharp’.

Do you have any idea to proceed with this issue? The .dll is found, there is no binding error thrown in the fusion log etc.

Ben · March 24, 2025, 7:11pm

Hi Julian,

It has been upgraded to the latest SkiaSharp 3.116.1 in beta105, and this will be applied to the next main release v14.3 by May. Can you use the latest beta for now and upgrade to v14.3 later?

Thanks,
Ben

Julian_Thoms · March 26, 2025, 11:34am

Hi Ben, thank you, this works for us!

Ben · March 26, 2025, 4:28pm

Julian, that’s great!

Julian_Thoms · April 7, 2025, 7:52am

Hi Ben, we have just upgraded our ThinkGeo Version to the latest beta (14.3.0-beta115) to test this.

However, after this upgrade, after loading in a layer, our scrolling does not work anymore - neither through scrollwheel nor through the interface on the left. Is this a known bug?

Ben · April 7, 2025, 9:13pm

Hi Julian,

We do find beta115 has the issue where the double-click/mouse wheel scrolling not zooming in correctly when the map is rotated. (it was correct in beta114). This issue has been fixed in today’s build beta116.

We do not see your issue though. I think beta105 is correct for you, right? can you let me know since which issue it started to have issues?

Thanks,
Ben

Julian_Thoms · April 9, 2025, 7:12am

Hi Ben, Thanks for your response.
I was on the latest stable branch previously and it worked. I have now tried the latest beta as of today (119 Wpf, 118 Core) and I still have the same issue.
Basically, without any layers, the extent updates properly, when loading in any layer, it will not anymore.

I have changed to the beta 105 and can confirm that this works here, so this seems to be an issue with ThinkGeo. If you need any more information please tell me what I can provide so you can fix this issue in the latest beta and for the release, thanks!

Ben · April 10, 2025, 1:56am

Hi Julian,

I couldn’t recreate the issue, but we did make some changes regarding map extent in the latest beta (119 Core, 120 Wpf), please have a try.

If the issue still exists, I think it might have some internal exception when loading the layer which stops the map from zooming. Can you put the following 2 lines in your code and see if you can find some useful information in your output window?

        ThinkGeoDebugger.LogLevel = ThinkGeoLogLevel.Error;
        ThinkGeoDebugger.LogType = ThinkGeoLogType.All;

If still no clue, can you

let me know starting from which version it started to have this issue?
show me your code about the layer, how it is initialized.

Thanks,
Ben

Julian_Thoms · April 10, 2025, 7:31am

Hi, I have updated thinkgeo to the latest beta and the scroll functionality has been restored. ThinkGeoDebugger gave me no errors. Initially it scrolled at only 1/4th the speed, but after playing with it a bit it has restored to normal speed. I didn’t change anything in the code however, that is why I wanted to mention that.
Thanks

Ben · April 10, 2025, 8:17pm

Hi Julian,

By “it scrolled at only 1/4th the speed” I think you meant the zooming animation is 1/4 of the regular speed, right?

If you just leave the map there for a while after it has been initialized, and then do the zooming, is it still slow?

Also, can you give me some idea how big the project is, like how many overlays, how many markers or popups are on the map? It should not have any noticeable slowdown unless you have hundreds of overlays/makers.

You can set the duration of the zooming animation in the code, but it should be consistent anyway.

Thanks,
Ben

Julian_Thoms · April 11, 2025, 10:42am

Hi Ben, sorry I was unclear, I meant that before, one tic of the scrollwheel would zoom me in 4x, and now it only zoomed in 1x if that makes sense.
I’d have to scroll 8 times to get the same zoom level as previously with only 2 scrolls.

However, I could not reproduce this issue yet, it happened after upgrading and disappeared after about an hour. Weird.

We attach meta information on each layer for our purposes, but the test setup was very small, with 2 Overlays and 1 Layer in 1 Overlay. No markers or popups, just a simple shapefile.

If it happens again I will open a thread with more debugging information, but I won’t be able to actively test this until the end of april, apologies.

Ben · April 11, 2025, 2:58pm

Hi Julian,

No problems! If that happens again, can you also let me know:

if double-click zooming in also has the same issue
if the count of MapView.ZoomLevelSet.GetZoomLevels() is more than you expected.

Thanks,
Ben

Julian_Thoms · May 16, 2025, 4:08pm

Hi @Ben , I seem to have found the reason for this.

We used to listen to the CurrentScaleChanged event and triggered Layer Visibility based on the Scale (So we can define the Min & Max Scale for a Layer, and each time the scale is changed if this value falls outside the current map scale, the layers are set as invisible).

However, with this upgrade, our logic slowed to a crawl. The logic is from v8 of ThinkGeo, so I’m just wondering if there is a native solution for this or if something has changed here from the Version 14.2.5 to now?

Our logic checks whether the extent is bigger / smaller than our min / max extent set and sets isVisible on the layer depending on the logic, as in, on: Layer.IsVisible

public Layer MapLayer { get; set; }

Julian_Thoms · May 16, 2025, 7:31pm

Just because you also asked for this information, the MapView.ZoomScales are:

	[0]	295829513.55892092	
	[1]	147914756.77946046	
	[2]	 73957378.38973023	
	[3]	 36978689.194865115	
	[4]	 18489344.597432557	
	[5]	  9244672.2987162787	
	[6]	  4622336.1493581394	
	[7]	  2311168.0746790697	
	[8]	  1155584.0373395348	
	[9]	   577792.01866976742	
	[10]   288896.00933488371	
	[11]   144448.00466744186	
	[12]	72224.002333720928	
	[13]	36112.001166860464	
	[14]	18056.000583430232	
	[15]	 9028.000291715116	
	[16]	 4514.000145857558	
	[17]	 2257.000072928779	
	[18]	 1128.5000364643895
	[19]	  564.25001823219475

And double clicking has the same issue

Ben · May 19, 2025, 9:49pm

Hi Julian,

It’s because CurrentScaleChanged is now be raised whenever the current scale is changed even during the zooming animation. For example, CurrentScaleChanged in the old version was raised only once when double clicking to zooming in, while it will be raised multiple times in the new version.

You can easily use another event to work it around. For example, MapView.OverlaysDrawing will be raised each time before rendering the overlays, which is the same timing as the old CurrentScaleChanged has.

You can even keep using CurrentScaleChanged if changing the visibility of an overlay instead of the layer, which avoids redrawing any layer and is more efficient. In our blackhole sample we do use CurrentScaleChanged to change the opacity of overlays, please check it out if you are interested.

samples/wpf/HowDoISample/Samples/MapNavigation/ZoomToBlackHole.xaml.cs · master · ThinkGeo / Public / Desktop Maps · GitLab

Sorry for the inconvenience, we usually avoid the breaking changes like this, but the new way is actually more correct and making more sense than the old one.

Thanks,
Ben