Building on other platform: getTime was not declared in this scope about aminogfx-gl HOT 9 CLOSED

Yes, just call group.visible(false) and the group will not be rendered at all. This improves performance.

For best performance reduce the number of layers. If too many pixels run through shaders you will get below 60 fps. Try layers.js. On Raspberry Pi 3 I get about 10 MP per frame at 60 fps. On Mali you should get similar values.

You can also switch to 3D mode where only visible parts will be rendered using a depth buffer (.depth(true)). However, the layers have to be on different z-values or results will be undefined (z-fighting).

The animation steps are calculated on the C++ level to get exact values. If you set the values manually they might be slightly off, especially if the JavaScript code processes other calculations. Adding native keyframe support might be a good idea.

from aminogfx-gl.

Use the RPi code as a template. You can remove the video code which works anyway only on VideoCore IV.

Mali-400 is a nice GPU. Do you have access to source code for OpenGL ES, EGL and HDMI output?

from aminogfx-gl.

I think there already is a 'visible' property. If you set that to false it should skip that node altogether.

from aminogfx-gl.

I figured out that obviously it has to do with the OS. I found references to specific RPI stuff in binding.gyp. Which makes sense. Now 'all I have to do' is add the OS and device I'm using.

from aminogfx-gl.

That's what I thought. I'm hoping to get the basics to work, so I'll remove the video code. Thanks for the suggestion. I believe the Mali has open source drivers and I'm using armbian, which claims to have OpenGL support.

I'll try it on my OrangePi first. Which also has the Mali chip, but can run Raspbian. Which is hopefully a smaller step than a completely different system.

I'm really hoping that the Mali is a little faster than the Raspberry's Broadcom chip. I'm trying to replace my OpenVG code with OpenGL. I render a lot of large images on the screen as a slide show with layers. I thought that switching from OpenVG to OpenGL would be a boost in performance. I guess I always thought that OpenGL works better with images/textures. But it's still not all that great. There are some things I can try to speed things up I hope, but going from 30 fps to around 20 fps is not what I wanted.

I quickly figured out that if you add nodes to a group with opacity 0, they still get processed. I now move them to x = 2500 to make sure they don't. Which works. Maybe this is something I could fix on a lower level than my own code. I guess there are more things like this I can try. Maybe detecting if a 'layer' is visible at all (and not behind another layer for example) and making sure it's not being processed if it isn't visible.
Also I'm not using the anim function, but setting the properties using a timer with a ~16ms interval (1000/60). This is because I use keyframes instead of instructions like go from here to there in this amount of seconds. So I kinda have to calculate all the properties for each frame.

I know this is a little off topic, but if I could pick your brain on some of these things that would be great. I really love AminoGfx. I found it only a few days ago, and from some small tests it seemed exactly what I was looking for. Unfortunately, now I'm rewriting my own code to use it, it seems that it needs a little more work (love) to get it up to 60 fps. I have a lot of questions, so I completely understand if you have better things to do :)

from aminogfx-gl.

Thank you for the tips!

I've tried the layers.js test and get around the same performance on my Pi3. I don't when I'm using my own code, but that could have something to do with the way it works. The whole thing is very dynamic and database driven.

I'll try 3D mode, which could help me out alot! I've been trying to detect which layers need to be rendered myself, but it doesn't give me the performance I would like. Also I can't detect partially visible layers and only render the visible part. So this could be really handy I guess. Do I need to compensate the size of the layers? I can imagine that something that is 'closer to the camera' is rendered larger than something further away. Also do I add the layers top down? So first the top layer with the highest z-value and then the one below it with a lower z-value? I can imagine that's the only way the engine can know if parts need to be rendered or not. What's the range of the z-value anyway? And what is the minimal difference between z-values to prevent z-fighting?

I've noticed little differences in positioning, but the way I'm using it, it doesn't really matter. Native keyframe support would be awesome. As would native sprite support. But I'm not sure if this library is maintained that actively. I could open a few issues with feature requests for if either of you has some spare time.

Again, I really love this library. As I said, I've worked with OpenVG before this using Node OpenVG Canvas. Which is a lovely library, but I've reached maximum performance on that. I believe Amino GFX can take it to the next level. Especially with the built in video support on the PI. It's awesome.

Edit: I just realized that it doesn't matter in what way I add the layers. Or at least it shouldn't.

from aminogfx-gl.

By default an orthographic projection is being applied. So there won't be a z-scaling unless you activate it:

const gfx = new amino.AminoGfx({
    perspective: {
        orthographic: false
    }
});

I tried some animated gifs using FFmpeg but this was only working on my Mac, on Raspberry Pi there were some issues. This would have been some kind of sprite support.

Feel free to contribute. Pull requests are always welcome.

from aminogfx-gl.

Thanks for the fast response. Animated GIFs would be a great start. Though eventually I think an actual sprite could use a full range alpha channel. Which would look a lot better.

I would love to contribute, but I have never actually programmed anything significant in C++ before. I do understand how annoying it is when people want more and more and never actually contribute themselves. So I'll give it a go. I do have a fix for a problem I've been having with this library. But I'm not sure if it is actually a real solution.

from aminogfx-gl.

Closing this thread.

from aminogfx-gl.