hexops
Canvas binding
Has anyone given any thought to using this for 2d and 3d canvas application scenarios ?
I was looking at Ubers new deck.gl and it's all based on the same concept of react in that only changed things are written to the Dom or canvas as it were.
I can't speak for others using Vecty obviously, but if you're looking for an 'official' response here:
Sure, of course you can use Vecty for 2d/3d canvas applications in just the same way that you can use React for it. For example, it's quite straightforward to create a canvas in a Vecty application:
func main() {
vecty.RenderBody(&PageView{})
}
type PageView struct {
vecty.Core
}
func (p *PageView) Render() vecty.ComponentOrHTML {
return elem.Body(
elem.Canvas(
... canvas properties here ...
),
)
}
Then you would use https://godoc.org/github.com/gopherjs/vecty#Mounter and https://godoc.org/github.com/gopherjs/vecty#Unmounter as the point where you would create a rendering loop for the canvas.
This is all to say that basically anything you can do in React, you can also do in Vecty. But Vecty's scope does not overlap with that of deck.gl from Uber. Someone would have to create a separate project which does something similar with Vecty in Go instead of using React in JS/TS/etc.
It's worth noting that although deck.gl is 'based on the same concept of react in that only changed things are written to the canvas as it were' it is not using React to do that. Just in the same way that you wouldn't use Vecty directly to implement that feature. Majority of this behavior is handled on the deck.gl side, with exception of being told "hey, the deck.gl component got a new property X with value Y" and reacting to that by altering some OpenGL/canvas state. e.g. React's componentWillReceiveProps and other lifecycle methods. It should be trivial to use https://godoc.org/github.com/gopherjs/vecty#RenderSkipper in place of that React lifecycle method to do the same thing in Vecty.
Also, on the note of how deck.gl works.. you should know that OpenGL is inherently a state machine. Graphics cards are, inherently, large state machines. The reason a GPU is so fast for tasks is because they are so stateful. The React model fits OK with OpenGL when you're doing something very specific (like what deck.gl is doing) but it starts to break down if you start trying to use more 'advanced' GPU features (like what you might find in most Unity3D games, for example) because GPU speed inherently comes from their statefulness and if you try too hard to remove that you lose that performance aspect. Note that I'm not saying that the React model is a bad choice for interacting with WebGL/GPUs/etc, but just that it's only suitable for some applications and not all.
Thanks so much for your assessment. You have alot of deep knowledge about this. I will get a demo going with basic 2d and 3d canvas.
Also I tried out neelance's WASM branch of golang and got some success with just basic stuff. Will try vecty out with WASM and see how it goes.
The other thing i want to try is using vecty to drive a desktop app that uses a few native components and a glfw window etc. I know shurcool was working of a driver that worked for both webgl and opengl.
Will report back if I get lucky :)
On Sat, 9 Dec 2017, 22:20 Stephen Gutekanst, [email protected] wrote:
I can't speak for others using Vecty obviously, but if you're looking for an 'official' response here:
Sure, of course you can use Vecty for 2d/3d canvas applications in just the same way that you can use React for it. For example, it's quite straightforward to create a canvas in a Vecty application:
func main() { vecty.RenderBody(&PageView{}) } type PageView struct { vecty.Core } func (p *PageView) Render() vecty.ComponentOrHTML { return elem.Body( elem.Canvas( ... canvas properties here ... ), ) }
Then you would use https://godoc.org/github.com/gopherjs/vecty#Mounter and https://godoc.org/github.com/gopherjs/vecty#Unmounter as the point where you would create a rendering loop for the canvas.
This is all to say that basically anything you can do in React, you can also do in Vecty. But Vecty's scope does not overlap with that of deck.gl from Uber. Someone would have to create a separate project which does something similar with Vecty in Go instead of using React in JS/TS/etc.
It's worth noting that although deck.gl is 'based on the same concept of react in that only changed things are written to the canvas as it were' it is not using React to do that. Just in the same way that you wouldn't use Vecty directly to implement that feature. Majority of this behavior is handled on the deck.gl side, with exception of being told "hey, the deck.gl component got a new property X with value Y" and reacting to that by altering some OpenGL/canvas state. e.g. React's componentWillReceiveProps and other lifecycle methods. It should be trivial to use https://godoc.org/github.com/gopherjs/vecty#RenderSkipper in place of that React lifecycle method to do the same thing in Vecty.
Also, on the note of how deck.gl works.. you should know that OpenGL is inherently a state machine. Graphics cards are, inherently, large state machines. The reason a GPU is so fast for tasks is because they are so stateful. The React model fits OK with OpenGL when you're doing something very specific (like what deck.gl is doing) but it starts to break down if you start trying to use more 'advanced' GPU features (like what you might find in most Unity3D games, for example) because GPU speed inherently comes from their statefulness and if you try too hard to remove that you lose that performance aspect. Note that I'm not saying that the React model is a bad choice for interacting with WebGL/GPUs/etc, but just that it's only suitable for some applications and not all.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gopherjs/vecty/issues/182#issuecomment-350506304, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwu4C4l9DS5whbsUMTGCc61qaWz-0ks5s-vmZgaJpZM4Q6LyW .
The other thing i want to try is using vecty to drive a desktop app that uses a few native components and a glfw window etc. I know shurcool was working of a driver that worked for both webgl and opengl.
Maybe not suitable for your exact application for some other reason, but Electron is very good for this in general if you're just trying to get a Go application (written in Vecty) to run on the desktop.
yeah been there done that with electron. your right. I am more into trying out something crazy just to see whats there.. you never know
On Sun, 10 Dec 2017 at 18:58 Stephen Gutekanst [email protected] wrote:
The other thing i want to try is using vecty to drive a desktop app that uses a few native components and a glfw window etc. I know shurcool was working of a driver that worked for both webgl and opengl.
Maybe not suitable for your exact application for some other reason, but Electron https://electronjs.org/ is very good for this in general.
a
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gopherjs/vecty/issues/182#issuecomment-350566132, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwiJaINX-K421c_8dfAvg7yUfyCojks5s_BvcgaJpZM4Q6LyW .
@slimsag
Here are my thoughts having played around with approaches....
I have been using Flutter for 2D for a 1 month now because i got a bit frustrated with gopherjs and Canvas using it with webviews for mobile and desktop. Something kind of interesting... Flutter is quite similar to Vecty in terms of how it works. Its not the same but its basically a Builder Design Pattern. Whats different is that Vecty targets a rendering engine that is the HTML DOM, and Flutter targets a rendering engine that is opengl , via SKIA. Flutter will be targeeting 3D soon they say.
SO, yeah i just wanted to highlight how SKIA is what everyone seems to use to get the job done, and they its a hell of a lot of work but vecty has the right architectural basis to be able to target WEB and opengl (desktop and mobile).
BUT the reall issue is all the work that Google did with making Material Design widgtes that are perfect, and the scrolling and gestures etc etc. Huge amount of work.
Getting realistic. Once golang works with WASM, i fele that gopherjs / vecty will be much more attractive because
- startup time reduced massivly.
- faster in general (WASM is close to c speed apparently). that means making the investment to make high quality webgl canvas and 2d GUI things work with vecty becomes really worth while.
There is a good quality Vectry to Material Design components mapping out too. https://gitlab.com/agamigo/forks/cute/tree/gh1-vecty-changes