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.

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

[FEATURE] Add Blazor ServerSide support #1921

Closed
Code-Chops opened this issue Jan 6, 2022 · 4 comments
Closed

[FEATURE] Add Blazor ServerSide support #1921

Code-Chops opened this issue Jan 6, 2022 · 4 comments

Comments

@Code-Chops
Copy link

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: #1834 ?

Thanks in advance!

@RChrisCoble
Copy link

RChrisCoble commented Jan 6, 2022

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
Copy link
Contributor

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
Copy link
Author

Code-Chops commented Jan 14, 2022

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 :)

@mattleibow
Copy link
Contributor

Duplicate of #1194

@mattleibow mattleibow marked this as a duplicate of #1194 Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants