High frequency custom drawing (client side)

0
0

Hi,

I’m re-evaluating WiseJ post full-release and currently very impressed with how the platform has progressed since Beta.

It would help me if you could suggest the best approach to developing a custom control that has high drawing frequency.

The control in question is one we have developed ourselves as a .NET control.  It is a time-line bar that smoothly scrolls horizontally with additional zoom in/out.  I am currently pondering how one would best convert this for use in WiseJ, obviously the actual GDI logic would probably be identical but:

  1. Drawing code on server-side, sending updates via Json to the canvas widget on the client side.
    OR
  2. Drawing code on client-side with config data only passed from server to client.

I am thinking probably the update frequency would prohibit approach [1], but I can’t yet prove or disprove this.  For [2] I wouldn’t know where to start, but I am not afraid of writing the canvas drawing code in Javascript – if this is the best way in the long run.

(I am assuming there is no magic available to convert .NET graphics drawing code into something that would execute on the client-side?)

Regards,

Mark

  • You must to post comments
0
0

Thanks for your update Mark !

To use C# 6 with Visual Studio 2012 or 2013 you can take a look here: http://alextselevich.com/2015/08/using-c-6-0-in-visual-studio-2012-and-2013/

Hope that helps.

Best regards
Frank

  • You must to post comments
0
0

Just thought I’d keep the thread up to date.

Using the examples and extension code I’ve recently managed to wrap one of our custom streaming media players in a WiseJ widget (the code is standard javascript).

This works very well, and I think the process for the high drawing frequency widget would probably be to convert the existing WinForms .NET drawing code from C# into client-side javascript and then wrap that in a WiseJ widget.  I’m now pretty confident this would work.

Just one minor niggle… (hardly)

The example way to wrap Widget events seem to be to use C# 6.0 features, including nameof().  Is there an pre-6.0 C# pattern that could work? (for example if using WiseJ on Visual Studio 2012)?

Mark

  • You must to post comments
0
0

Also you could look at Bridge.net since it is completely open source C# => JS transpiler that might make for some really great synergy.

  • You must to post comments
0
0

Very interesting. I’ll take a look into DuoCode for sure.

The Canvas control has a LiveUpdate property, when set to true, all canvas calls are pushed to the client. Otherwise it collects the calls into a list and sends them back when the canvas widget “asks” for an update. Usually when the widget asks for a set of records we use http because we can match request/response and process the incoming data.

So the trade off in the Canvas control is to either update the widget on each canvas instructions, or updated it all at once at the end of the processing cycle.

Try also the BackgroundTasks example . It uses 3 Canvas controls to draw the lines as they are sorted in background tasks.

/Luca

  • You must to post comments
0
0

Hi Luca,

I have now run “IsWebSocket” on a button press rather than in the Load and is it returning True.

I have incorporated the ProgressCircle example code and that is another interesting method, so thanks for mentioning that.  Just one question, should the canvas updates come via web-sockets now that it appears that web-sockets are enabled?  It appears to be updating via post-backs.

We have in the past developed full javascript client-side “controls” using DuoCode (http://duoco.de/) and I’m thinking that there may be a synergy here in that the drawing code (control) could be developed in DuoCode and somehow integrated with WiseJ.  With the data structures simply passed from the server.

Thanks for your help so far, I will continue to experiment.

Mark

  • You must to post comments
0
0

Hi Mark,

If you check IsWebSocket when the application is loaded  in Program.Main() it will always be false since the first load is always http and the protocol hasn’t switched yet. You can check Application.Browser.Features.webSocket to see if the client supports it. In subsequent requests Application.IsWebSocket will return true.

However, not all requests coming in from Wisej are always websocket. Data requests from paged/cached data stores (datagrid, listview, fullcalendar, …) are all http requests. All image resources and postbacks are http requests since they are managed by the browser. And the UserPaint technique is simply an image request so while processing the Paint event you will always have IsWebSocket = false.

I don’t know what kind of update speed you need. User paint may not be the right approach. Wisej also supports canvas (HTML5) drawing (see the ProgressCircle extension. You can also try the Wisej.Web.Canvas control. It’s different from user painting, it uses a canvas element on the client and sends actual drawing instructions to the client.

Depending on the complexity of the chart you have created, a third option would be to write client side html canvas or svg drawing and get the data from wisej, as I did in the smoothie example (the data is coming from the server). As Thomas suggested, there are many javascript libraries that could help with the low level svg or canvas drawing, animation, zooming, etc. Wisej can turn any of those into a server side component.

HTH

Best,

Luca

 

  • You must to post comments
0
0

Hi Thomas/Luca,

With regards to the required update frequency, yes the demo at:

http://demo.wisej.com/smoothie

Is pretty much the type of frequency required, however maybe slightly less than that as most the updates occur because of a mouse drag operation or a mouse zoom in/out operation.

I have tried to build a simple test project to see how fast the WiseJ control paint initiated drawing code operates (over web-sockets).  I am running the project under IIS on Windows 10 (although was built using Visual Studio 2017 on Windows 7) and no matter what I try I can’t get the ‘Application.IsWebSocket’ property to become TRUE and the updates are falling-back to using standard HTTP.

Can you give me any other ideas what to try?

Regards

Mark

 

  • You must to post comments
0
0

Luca it would be cool if you turn this in extension!

it is possible to have a tutorial how do you have create this demo using this external js?

thanks

Cristian

  • Luca (ITG)
    Will try. This one was particularly easy. But the integration approach highly depends on how the widget works. The problem is that many third party javascript widgets support only one way options, meaning that if anything changes you need to destroy and recreate the widget. Others support updating only some of the properties. When turning it into an extension (instead of using it directly with Wisej.Web.Widget, as you’d do in an angular or asp.net app) the resulting Wisej control/widget has to be able to update itself dynamically so there is some plumbing work to do.
  • You must to post comments
0
0

Something like this?

http://demo.wisej.com/smoothie

Uses this:

http://smoothiecharts.org/

Will probably turn it into an extension.

  • You must to post comments
0
0

Hi Mark,

thanks for your feedback. 😉

I do also see these two approaches, both should work really nice with Wisej. Which one to pick is a matter of discussing the pros and cons of each approach. I am not aware of a tool that converts C# to JS as you describe it.

Can you explain a bit further what you mean with “high frequency”? Maybe you can simply give it a try because I suspect that the GDI drawing part will indeed be the same in Wisej. Alternatively, you might want to evaluate D3, which is commonly used for such tasks:
https://d3js.org/

Best wishes
Thomas

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.