search

mono / SkiaSharp

SkiaSharp is a cross-platform 2D graphics API for .NET platforms based on Google's Skia Graphics Library. It provides a comprehensive 2D API that can be used across mobile, server and desktop models to render images.
MIT License
4.42k stars 535 forks source link

[FEATURE] Add Blazor ServerSide support #1921

Open Code-Chops opened 2 years ago

Code-Chops commented 2 years ago

At this moment I have 2 ways to run my application: Blazor WebAssembly (for production) and Blazor ServerSide (for a faster and better debugging experience).

At this moment SkiaSharp does not support Blazor ServerSide:

Unhandled exception rendering component: SkiaSharp currently only works on Web Assembly

Could support for ServerSide be added to SkiaSharp? Or is it related to this issue: https://github.com/mono/SkiaSharp/issues/1834 ?

Thanks in advance!

RChrisCoble commented 2 years ago

I've been discussing this support with @mattleibow and @danroth27 for probably close to a year.

They understand the UC and it's technically feasible, but probably requires SkiaSharp on both ends (WebAssembly and server) with the server packaging up the draw calls to send to the client for rendering. That being said, I've asked that this be supported over in the Microsoft.MAUI.Graphics repo instead of SkiaSharp so it's in the core 2D .Net drawing API directly. Note: MAUI.Graphics is slated to support Blazor Client in the first release of MAUI timeframe (June).

Perhaps there's an architecture which can provide this functionality in SkiaSharp directly then it's consumed in MAUI.Graphics so both benefit, although in MAUI.Graphics supports a variety of backend drawing API's besides SkiaSharp, so it probably makes more sense to support Blazor Server in MAUI.Graphics.

gmurray81 commented 2 years ago

Would be curious about your use case. I think the bigger problem and what makes this scenario uninteresting to me, is latency. Let's say your round trip time to the server gets upward of 200ms, this means if you are rendering as a direct response to user input there would be a very perceivable delay between when you interact with some interactive graphics and when they actually update.

Furthermore that rtt isn't even stable and could spike up and down. For video delivery, the usual strategy is to delay the content enough that you can eat ping spikes and keep things appearing to happen in real time, but this is why live video streaming usually has such large inherent delay between when the content is being generated and when it is being delivered.

One solution for that is just to have a ton of servers in different regions and try to ensure that rtt is always as low as possible (e.g. streaming game services).

This leads me to believe that the main use cases for this would be for scenarios where a perceived delay between input and graphics reacting wouldn't be important.

Code-Chops commented 2 years ago

Yes you are right that is not really feasible/necessary in production. But it would be easy for faster debugging. Blazor WebAssembly takes more time to debug. But you are right; the use-case is not important to implement this feature :)