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.

Sign up for GitHub

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

Jump to bottom

Any examples? #1

Open
tomduncalf opened this issue Aug 24, 2017 · 22 comments
Open

Any examples? #1

tomduncalf opened this issue Aug 24, 2017 · 22 comments

Comments

@tomduncalf
Copy link

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

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

@msageryd
Copy link

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

tomduncalf commented Dec 19, 2017 via email

@msageryd
Copy link

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

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

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

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

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

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

robclouth commented Dec 19, 2017 via email

@msageryd
Copy link

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?
image

@msageryd
Copy link

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

robclouth commented Dec 21, 2017 via email

@msageryd
Copy link

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

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

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

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

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

robclouth commented Dec 21, 2017 via email

@msageryd
Copy link

msageryd commented Dec 21, 2017 •
edited
Loading

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

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

@tomduncalf
Copy link
Author

tomduncalf commented Dec 31, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@robclouth @msageryd @tomduncalf @nuttylord