-
Notifications
You must be signed in to change notification settings - Fork 70
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.
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
i.MX6 poor canvas performance #198
Comments
It is always difficult to give some advise in this kind of questions without checking in detail the hardware or how you created the image for your target device. Anyway, I would try to remove |
Thanks, I'll try that and report back. But if I remember correctly I started out like without it, only adding it after reading about it in the performance wiki page. I know it's hard with general advice, so maybe a simpler, first question from me would be if I can expect better performance than this? I simply want to use a vector based map solution, but the performance is just not acceptable (like 2-4fps and crazy high cpu). |
I can tell you I get a way better result with my rpi 3b+ with an image I generated some weeks ago using libwpe fdo backed, but I doubt that answers the question for your specific device and setup. Maybe someone using your hardware and setup can answer that question. As a general advise I would say you need to evaluate what operations your web application requires and if it is expected the amount of cpu it requires in that specific hardware, to make sure if there is a bug in the stack or if the application is just too much for the device, or you have to change/configure wpe/yocto to use more cpu/gpu, or in a different way. A lot of options :-). |
Allright, disabling accelerated 2dcanvas increased the FPS to about 20, so thanks for that advice! However (ofcourse) it's still running in the CPU, making our map solution sluggish. Running a native demo from |
This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This issue was closed because it has been stale for 7 days with no activity. |
I don't think this is solved. |
I wasn't able to get any further and had to pick a different track, so I wont be updating this issue any further. Feel free to close if you don't want to keep it for your sake. |
I've also run into this issue. I'm able to get about 11 fps with 90% CPU usage on average using the same test. What did you switch to @gust1n ? |
Sorry for the confusion, I had to switch to a software solution that didn't require the same performance (my application was maps so used prerendered tiles instead of vector) |
I'm actually doing the same thing, using maps but having speed issues with vector tiles. Are you serving pre-rendered tiles or rendering on the server? |
Hehe okay, after spending considerable time with these performance issues I ended up using HERE maps pre rendered tiles instead of their vector based solution. I wish you the best of good luck since I'm not actively working on this issue anymore :) |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
Hello, and thanks for a great project!
We're developing a web-based GUI for an electric motorbike, using cog and wpewebkit for running the frontend. However, when starting developing the maps, we discovered that the webgl/canvas performance is really bad.
Hardware: Apalis i.IMX6Q
Relevant config:
We're using the proprietary galcore module, which we can see gets loaded by the kernel. We've also successfully run demos, indicating the GPU is working from the package
imx-gpu-viv-demos
, which renders much more complex graphics.But when running e.g
http://clockmaker.jp/labs/120202_html5_performance/canvas.html
, we get around 3fps in cog, and the CPU is around 200%.Do you have any ideas what might be the issue, it seems that it's using the CPU instead of the GPU, happy to provide more info if it helps.
The text was updated successfully, but these errors were encountered: