Any examples? - Githubissues

tomduncalf commented 7 years ago

Hey,

I'm really interested to try this out, if it still works. Do you have any examples?

I'm getting

2017-08-24 17:29:08.115 nanovgtest[27572:1761516] Failed to bind EAGLDrawable: <CAEAGLLayer: 0x61000002a040> to GL_RENDERBUFFER 1
2017-08-24 17:29:08.116 nanovgtest[27572:1761516] Failed to make complete framebuffer object 8cd6

when I try to use it.

Cheers, Tom

nuttylord commented 7 years ago

+1, all i want to use this for is drawing an arc as performantly as possible.

msageryd commented 6 years ago

+1. I'm really interested in this. Desperately need something more speedy than react-native-svg. This seems to be an option, but I can't get it rolling.

It seems that createReactNativeComponentClass has move into folder Renderer/shims. I updated the path in index.js, but I get into trouble anyway in form of: Invariant Violation: Element type is invalid ... Check the Render method of Surface.

The call stack involves createFiberFromElementType. I suspect that the new fiber stuff in React is getting in the way of the nanovg implementation. I honestly don't have a clue of what fiber does, but is has a cool name.

tomduncalf commented 6 years ago

FYI I ended up going with a shader using gl-react-native. Nowhere near as convenient as an SVG-like interface but it performs like I need it to!

On 19 Dec 2017, at 07:41, Michael Sageryd notifications@github.com wrote:

+1. I'm really interested in this. Desperately need something more speedy than react-native-svg. This seems to be an option, but I can't get it rolling.

It seems that createReactNativeComponentClass has move into folder Renderer/shims. I updated the path in index.js, but I get into trouble anyway in form of: Invariant Violation: Element type is invalid ... Check the Render method of Surface.

The call stack involves createFiberFromElementType. I suspect that the new fiber stuff in React is getting in the way of the nanovg implementation. I honestly don't have a clue of what fiber does, but is has a cool name.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

msageryd commented 6 years ago

Thanks @tomduncalf. I thought gl-react-native was just for bitmap manipulating. Can you actually draw shapes with gl-react-native? Do you have an example?

BTW. I think nanovg might have broke in a recent RN upgrade. Here is what the shim file is exporting. I interpret this as do-not-use :)

module.exports = __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED.createReactNativeComponentClass;

tomduncalf commented 6 years ago

Yeah it is just for bitmap/3D stuff. I'm using it to draw arcs primarily, using a shader to do so (and regl to execute the shader).

I based it on this: https://github.com/glslify/glsl-circular-arc, but it's definitely a lot harder work than something higher level. If you want performance for drawing and you can fit within the constraints though, then a shader is probably going to get you the highest performance by quite a long way as the GPU is really good at drawing stuff :)

robclouth commented 6 years ago

Hey gang, sorry for the delayed reply. I've been busy with other work recently. I'll have a look over the xmas hols, and see if I can get to the bottom of it. Does it work on RN 0.40.0?

msageryd commented 6 years ago

Great of you to chime in! I'm really interested in trying this out.

I installed 0.40 but this RN version might have been a lemon. Nothing works..

Got a bit longer with 0.41. I could start the fresh app, but as soon as I added art-nanovg I got weird errors, "Packager has encountered an internal error". I tried to reset the packager cache without luck.

It might be that older RN versions won't play well with newer XCode or something.

Sorry that I couldn't help with this. Is there anything else I can do?

msageryd commented 6 years ago

I have read through all breaking changes from 0.40. Couldn't find anything that should have impact here. I could have missed something of course. The only thing was an altered .babelrc search algorithm, but it shouldn't matter since you don't have a local .babelrc in your module.

msageryd commented 6 years ago

The original nanovg library has had a bunch of updates though. Your fork is alost a year old. Seems far fetched, but could this be something that needs attention?

robclouth commented 6 years ago

I'm really not sure how to go about it without digging in fully, which I don't have time right now sorry. Are you using the new iOS? It could be that we need to merge in from the main nanovg repo if they've fixed stuff there. Have you checked there to see if there's issues relating to the ios version you're using?

On Tue, 19 Dec 2017 at 20:17 Michael Sageryd notifications@github.com wrote:

The original nanovg library has had a bunch of updates though. Your fork is alost a year old. Seems far fetched, but could this be something that needs attention?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/robclouth/react-native-art-nanovg/issues/1#issuecomment-352858893, or mute the thread https://github.com/notifications/unsubscribe-auth/ABL9orpFSQEQCEpur8GsLvbN-zaQli2-ks5tCAuugaJpZM4PBn5S .

msageryd commented 6 years ago

Yes I'm on latest iOS, but the build target in XCode is 8. I tried with other target versions, but lo luck.

At first glance I couldn't find anything. But the commit comments are not that verbose and I'm not comfortable with this level of programming. There was a fix for compiling under OSX 12, but I'm on 10 so that shouldn't matter.

Why did you opt for a separate fork? Was there any RN specific stuff that needed to be added? The master repo seems to be quite active.

Unfortunately I'm not fluent in XCode either, but I did my best and tried to see what happens.

libc++abi.dylib: terminating with uncaught exception of type NSException

Does this call stack give you any clues?

msageryd commented 6 years ago

I got it sorted out. Some changes are needed in index.js. I'll get back with a PR when I've done some more testing.

robclouth commented 6 years ago

Thanks. Index.js was lifted straight from react native ART, have a look in there. Sorry for not being able to help. I'll merge asap.

On Thu, 21 Dec 2017, 18:33 Michael Sageryd, notifications@github.com wrote:

I got it sorted out. Some changes are needed in index.js. I'll get back with a PR when I've done some more testing.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/robclouth/react-native-art-nanovg/issues/1#issuecomment-353410685, or mute the thread https://github.com/notifications/unsubscribe-auth/ABL9oqT7x06znVtOk-BEZQhuMcR135Gjks5tCpaGgaJpZM4PBn5S .

msageryd commented 6 years ago

I already made the changes and I have it up and running in RN 0.51. Unfortunately it doesn't seem to solve my performance problem. I suspect that my problem lies in the bridge communication rather than in the actual graphics rendering.

I'll get back with a PR tomorrow.

tomduncalf commented 6 years ago

@msageryd I'm doing fairly complex 60fps graphics rendering using gl-react-native and performance is OK. I've done a lot of performance analysis throughout this project and I don't think bridge communication is a huge overhead in most scenarios.

I'd recommend profiling your app in Instruments using the Time Profiler – it'll show you which calls are taking up the most time. When I was doing rendering with ART or react-native-svg most of the time was spent in the CoreGraphics draw calls – it seems that drawing stuff, especially arcs, is just quite expensive.

Before you do go down the GL shader wormhole though, it's worth also profiling your RN app with the standard React profiler and checking you aren't re-rendering stuff more than you need to. For example, it's worth splitting your drawing up into multiple components and making judicious use of shouldComponentUpdate to ensure you draw as little as possible in response to changes in state.

I plan to write up some of what I've learnt about doing this kind of thing with RN in the new year so I'll be sure to share it with you :)

tomduncalf commented 6 years ago

One other thing worth noting, is that if you are doing something 60fps then you might find that the usual way you'd write code isn't helping performance. Micro-optimisations become important at that point - e.g. avoiding garbage collection and reusing objects as much as possible.

It's also worth using the Systrace support in React Native to output a trace which you can then analyse with chrome://tracing to see what is taking up most of your time. The results can be surprising – e.g. React component reconciling can end up getting quite expensive, so its worth investigating if you can draw using setNativeProps somehow to bypass all that.

msageryd commented 6 years ago

@tomduncalf Wow, thanks for invaluable tips I have never been digging this deep into RN. Didn't have a clue of which tools to use.

@robclouth The changes in my PR are needed for RN >= 0.50. How would you like the PR? Should I just make the changes in index.js som you can package it in versions/branches or whatever you do to distinguish between compatible RN versions?

msageryd commented 6 years ago

The Pull is Requested..

Thank you @robclouth for your work on this lib. Unfortunately it will not suit me for now. A couple of problems hit me:

path.arc()is missing in your serializer. There is a path.addArc() but when I try to use it the app crashes.
There is a peculiar lag when many objects are drawn. It's almost as if the coordinate reading are kind of lazy and only read after other stuff is rendered. I don't get this lag with ART.
Lastly, my bottleneck does not get solved by nanovg. I need to look elsewhere in my code :(

robclouth commented 6 years ago

Thanks for the pr even you're aren't gonna use it! It was helpful for me for for drawing complex graphs, esp on android. Sorry to hear it wasn't useful.

On Thu, 21 Dec 2017, 20:24 Michael Sageryd, notifications@github.com wrote:

The Pull is Requested..

Thank you @robclouth https://github.com/robclouth for your work on this lib. Unfortunately it will not suit me for now. A couple of problems hit me:

-

path.arc()is missing in your serializer. There is a path.addArc() but when I try to use it the app crashes.

There is a peculiar lag when many objects are drawn. It's almost as if the coordinate reading are kind of lazy and only read after other stuff is rendered. I don't get this lag with ART.

Lastly, my bottleneck does not get solved by nanovg. I need to look elsewhere in my code :(

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/robclouth/react-native-art-nanovg/issues/1#issuecomment-353436095, or mute the thread https://github.com/notifications/unsubscribe-auth/ABL9otD0LEzjZdxeWA22gYo7LnHPsBd_ks5tCrBmgaJpZM4PBn5S .

msageryd commented 6 years ago

@tomduncalf Would you be willing to sell a couple of hours of your time to me? Maybe just an hour or two for picking your brain on the performance stuff.

My animations can not be done declarative since they are all driven by user input (touches). When the underlaying blueprint (jpg) is paned/zoomed I need so move/scale my graphics which I paint on top of the blueprint.

I'm now investigating if setNativeProps can help with the performance, but the ART objects don't seem to have/expose setNativeProps(). I've never used setNativeProps, so it's a hard way for me to go. Since all my objects are affected in the same way (deltaX, deltaY, scale) I thought of saving a ref to each visible component in an array and update the transform prop on those objects via setNativeProps when the underlaying blueprint is transformed. I don't even know if setNativeProps can be used this way.

Would you suggest going further with the setNativeProps, or should I investigate other means?

@robclouth, sorry for using your issue-thread for discussion. I couldn't find any way to send messages directly to a GitHub user.

msageryd commented 6 years ago

@robclouth do you know if setNativeProps() can be used on your Surface? The regular ART Surface does not seem to implement this.

tomduncalf commented 6 years ago

Hey Michael,

Sorry I missed your earlier message! My time is a bit scarce at the minute but please feel free to drop me a line at tom@tomduncalf.com with a little more information about what you are doing and I’ll let you know if I think I can help!

Thanks, Tom

On 21 Dec 2017, at 22:14, Michael Sageryd notifications@github.com wrote:

@tomduncalf Would you be willing to sell a couple of hours of your time to me? Maybe just an hour or two for picking your brain on the performance stuff.

My animations can not be done declarative since they are all driven by user input (touches). When the underlaying blueprint (jpg) is paned/zoomed I need so move/scale my graphics which I paint on top if the blueprint.

I'm now investigating if setNativeProps can help with the performance, but the ART objects don't seem to have/expose setNativeProps(). I've never used setNativeProps, so it's a hard way for me to go. Since all my objects are affected in the same way (deltaX, deltaY, scale) I thought of saving a ref to each visible component in an array and update the transform prop on those objects via setNativeProps when the underlaying blueprint is transformed. I don't even know if this if setNativeProps can be used this way.

Would you suggest going further with the setNativeProps, or should I investigate other means?

@robclouth, sorry for using your issue-thread for discussion. I couldn't find any way to send messages directly to a GitHub user.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

robclouth / react-native-art-nanovg

Any examples? #1

path.arc()is missing in your serializer. There is a path.addArc() but when I try to use it the app crashes.

There is a peculiar lag when many objects are drawn. It's almost as if the coordinate reading are kind of lazy and only read after other stuff is rendered. I don't get this lag with ART.