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.

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

Open
gust1n opened this issue Oct 6, 2020 · 13 comments
Open

i.MX6 poor canvas performance #198

gust1n opened this issue Oct 6, 2020 · 13 comments

Comments

@gust1n
Copy link

gust1n commented Oct 6, 2020

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:

PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-rdk"
PACKAGECONFIG_pn-wpebackend-rdk = "imx6"
IMAGE_INSTALL_append = " wpewebkit cog"
PACKAGECONFIG_append_pn-cairo = " glesv2 egl"
PACKAGECONFIG_append_pn-wpewebkit = " 2dcanvas"

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.

@alexgcastro
Copy link

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 PACKAGECONFIG_append_pn-wpewebkit = " 2dcanvas" and check how that works, 2d rendering in the gpu using cairo is something we do not recommend unless you know what you are doing, that code is not compiled by default and that cairo backend not used. 2d rendering APIs using the GPU is a challenging problem that everyone is still trying to solve nowadays, cairo-gl does some triangulation computation to implement the operations that can easily cause a lot of performance bottlenecks, I do not know anyone that is using it nowadays.

@gust1n
Copy link
Author

gust1n commented Oct 6, 2020

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).

@alexgcastro
Copy link

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 :-).

@gust1n
Copy link
Author

gust1n commented Oct 7, 2020

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 imx-gpu-viv-demos can render complex 3d stuff in hundreds of FPS, barely touching the CPU utilization. Does anyone know of any other way of increasing the html5 canvas performance?

@github-actions
Copy link

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.

@github-actions github-actions bot added the no-issue-activity Stale issue label label Mar 18, 2022
@github-actions
Copy link

This issue was closed because it has been stale for 7 days with no activity.

@otavio
Copy link

otavio commented Mar 25, 2022

I don't think this is solved.

@philn philn reopened this Mar 25, 2022
@philn philn removed the no-issue-activity Stale issue label label Mar 25, 2022
@gust1n
Copy link
Author

gust1n commented Mar 25, 2022

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.

@adahl5
Copy link

adahl5 commented Apr 26, 2022

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 ?

@gust1n
Copy link
Author

gust1n commented Apr 26, 2022

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)

@adahl5
Copy link

adahl5 commented Apr 26, 2022

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?

@gust1n
Copy link
Author

gust1n commented Apr 26, 2022

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 :)

@github-actions
Copy link

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.

@github-actions github-actions bot added the no-issue-activity Stale issue label label Oct 23, 2022
@psaavedra psaavedra added work-in-progress and removed no-issue-activity Stale issue label labels Oct 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants