support accelerated_2d_canvas

Bug #1352631 reported by Maxim Ermilov
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
Critical
Justin McPherson
1.2
Fix Released
Undecided
Unassigned

Bug Description

this option enabled by default on android.
It will be useful for html5 games.

I test few games with google-chrome with accelerated_2d_canvas enabled, they works fine.
canvas render trash on oxide (with accelerated_2d_canvas enabled)

Revision history for this message
Maxim Ermilov (zaspire) wrote :

some stats from nexus 4:
android webview (4.4.4): 30-50fps
oxide: 12-15 fps

Revision history for this message
David Barth (dbarth) wrote :

Chris, this is games using the <canvas> tag and drawing on this surface. Is there a either a way to enable that accelerated 2d canvas feature? Or alternatively, is thee another rendering path to use to benefit from HW acceleration built into Oxide?

Revision history for this message
Adnane Belmadiaf (daker) wrote :

not sure if it's related but i have an HTML5 canvas game on the store(Demonition) that is slow compared to android & ios

Changed in oxide:
importance: Undecided → High
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

The issue here is that accelerated canvas is currently blacklisted on Chrome Linux because of driver bugs. In order to enable it safely at runtime on specific hardware, we need to implement support for gathering GPU info to feed in to the GPUDataManager, and then we need to modify the GPU blacklist to enable it.

But the description is still not clear to me. I did ask for some more info on IRC a while ago - it's not clear from the description whether this bug is just about accelerated canvas not being enabled, or whether it's also saying that it doesn't work properly when it's enabled anyway

Revision history for this message
Maxim Ermilov (zaspire) wrote :

> accelerated canvas not being enabled
no, It does not work properly with oxide.
I did special build with enabled acceleration, but canvas wasn't rendered properly.

on other hand, It does work with chrome (with disabled blacklist & forced 2d acceleration)

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

How did you test this works on Chrome? After talking with Chris, AIUI, this is disabled for all Chromium on linux because it doesn't work. This will need someone familiar with the Chromium graphics stack to fix.

Revision history for this message
Maxim Ermilov (zaspire) wrote :

> because it doesn't work
it's unstable, but it works (depend on driver).

can be enabled in chrome://flags/

Revision history for this message
Maxim Ermilov (zaspire) wrote :
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

Yes, it's disabled because it's unstable across a wide range of drivers. Did you test that it works in Chrome for Android on the same hardware you also verified that the canvas doesn't render correctly with Oxide?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Maxim, on what platform are you testing this? Desktop, Touch, Android, something else?

If I look at chromium-browser and look at chrome://gpu/, I see this:
Problems Detected
 Accelerated 2d canvas is unstable in Linux at the moment
 Disabled Features: accelerated_2d_canvas

There are other features that are also disabled.

So this is an upstream chromium api issue. I think we would need an expert in this area to address this fully.

After talking to Chris, *if* we were going to go about this ourselves, we would need to:
 a) stop automatically disabling the feature on all linux builds
 b) test that this works on our supported devices
 c) add an entry to the gpu database (VENDOR and DEVICE under Driver information in chrome://gpu) for devices where it is known *not* to work
 d) possibly updating the driver bug workarounds list for any quirks
 e) implement a mechanism to gather gpu data so chromium api could query these databases and turn on the feature when appropriate

From 'c', this is actually quite tricky because upstream has determined this is too buggy to implement everywhere themselves, and we don't have all the hardware out there. Also, 'e' is not particularly difficult and would take time.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Presumably, 'Linux' in upstream's mind means Linux drivers. However, if the devices are using android drivers, then perhaps when implementing 'e' we can determine if we are running a linux driver. We can then add a special entry to the gpu database for disabling the accelerated 2d canvas. Then if we detect if we are running a linux driver, we use this blacklisted entry. We still need the mechanism in 'e' to get the information on the android drivers to feed into the database. By doing this, we maintain upstream's position of not enabling the accelerate 2d canvas, but it will be enabled with android drivers that are known to work (based on upstream's own database).

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

It would be possible to only disable on desktop linux, although that won't solve the problem that accelerated canvas doesn't render correctly on the device. But it's still not clear if this is a device issue or an Oxide issue (was Chrome verified to work on the same device that Oxide doesn't work on?)

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

Just tested this running Chrome on Android on mako

The game at http://dungeonfury.playcanvas.com/ played smoothly

chrome://gpu/ reported
Canvas: Hardware accelerated

Revision history for this message
Maxim Ermilov (zaspire) wrote :

>it's disabled because it's unstable across a wide range of drivers.
It's enabled on android 4.4

> Did you test that it works in Chrome for Android on the same hardware you also verified that the canvas doesn't render correctly with Oxide?
game works fine with enabled 2d_acceleration on chrome(desktop) & android(nexus 4).
rendering problems appear on oxide(desktop).
I did not test it on device with oxide.

> a) stop automatically disabling the feature on all linux builds
It can be an option (disabled by default).

Revision history for this message
Victor Tuson Palau (vtuson) wrote :

so can we enable this for android-drivers based devices?

Revision history for this message
Maxim Ermilov (zaspire) wrote :

> so can we enable this for android-drivers based devices?

yes

tags: added: rtm14
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ok, we seem to not be communicating well.

The Oxide team needs to understand what has been tested in clear terms in order to know if we can proceed with enabling this when using Android drivers at all.

Please answer 'yes' or 'no' for each of these with framerates (<URL> should be the same for all tests, eg http://dungeonfury.playcanvas.com/ (but can be something else)):

1. does <URL> work on Chrome for Android on krillin?
2. does <URL> work on Chrome for Android on mako?
3. does <URL> work on Chrome for Android on flo?
4. does <URL> work on Chrome for Android on manta?
5. [OPTIONAL] does <URL> work on Chrome for Android on hammerhead?

Have you tested Oxide specifically with '2d canvas enabled'? If not and the testing above supports it, we can provide a test oxide build in a PPA with '2d canvas enabled' enabled. Once you are able to test Oxide with '2d canvas enabled', please answer 'yes' or 'no' for each of these with framerates:
1. does <URL> work on Oxide for Ubuntu Touch on krillin?
2. does <URL> work on Oxide for Ubuntu Touch on mako?
3. does <URL> work on Oxide for Ubuntu Touch on flo?
4. does <URL> work on Oxide for Ubuntu Touch on manta?
5. [OPTIONAL] does <URL> work on Oxide for Ubuntu Touch on hammerhead?

When the above is done and it is demonstrated that our target hardware works with '2d canvas enabled' on Oxide for Ubuntu Touch, we can understand the scope of the work and get it assigned to someone.

Changed in oxide:
status: New → Incomplete
Revision history for this message
Maxim Ermilov (zaspire) wrote :

> for each of these with framerates
I don't have this devices.

as I mention before, speed up is more then _300_% (upto 1000 %).

> Have you tested Oxide specifically with '2d canvas enabled'?
oxide have HUGE rendering issues. (image completly broken)

Changed in oxide:
status: Incomplete → New
Changed in oxide:
importance: High → Critical
Revision history for this message
David Barth (dbarth) wrote :

I will summarize the report at this stage.

1. We want accelerated canvas_2d support, because alternatives won't help. Existing applications use it, few use the old SVG support. And we expect that this feature will let us get more of those HTML5 games.

2. Maxim has been gathering test results in the following configurations

N4/mako, Android, Google Chrome: 30-50FPS
N4/mako, Ubuntu, Oxide: 12-15FPS
X86/desktop, Ubuntu, Google Chrome without accelerated_2d_canvas: low perf
X86/desktop, Ubuntu, Google Chrome *WITH* accelerated_2d_canvas: 60FPS (maxed by vsync probably)
X86/desktop, Ubuntu, Oxide: rendering artifacts, can't read what's on the surface; may hide low FPS as well

We also observed that accelerated_2d_canvas is enabled on Android for certain chipsets: it is hardcoded in a whitelist for N4 and a couple others: https://chromium.googlesource.com/dart/dartium/src/+/7c84e6ccb7c17fbe063e91e8507a6e2220b5ad31%5E%21/#F0

3. At this stage there are still open questions like:

a/ If we enable accelerated_2d_canvas in Oxide for armhf on N4: is the rendering correct? or broken like on the desktop?
b/ If we enable accelerated_2d_canvas in Oxide for armhf on N4: how is the performance?
c/ does the above apply to other models like krillin?

Revision history for this message
David Barth (dbarth) wrote :

Maxim is building Oxide (current) with the flag enabled and will test on armhf/mako to check a/ above at least, and /b to the extent applicable.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

David Barth's team is driving this bug now, and we spoke and thought this is a 2014-09-25 target, so marking the bug as such.

tags: added: touch-2014-09-25
Revision history for this message
Maxim Ermilov (zaspire) wrote :

something changed in chrome codebase.
i am getting 60 fps with new oxide & chrome (with disabled 2d_acceleration).
same 10 fps on the device.

Revision history for this message
David Barth (dbarth) wrote : Re: [Bug 1352631] Re: support accelerated_2d_canvas

To clarify, the test results are :

Desktop/x86 - Oxide 1.2.1, default options - 60 FPS (better)
N4/armhf - Oxide 1.2.1, default options - 8-10 FPS (same)

Maxim didn't manage to build oxide in a click chroot, and is now trying the
cross-compilation instructions sent by Chris.

On Sun, Sep 14, 2014 at 6:08 PM, Maxim Ermilov <email address hidden>
wrote:

> something changed in chrome codebase.
> i am getting 60 fps with new oxide & chrome (with disabled
> 2d_acceleration).
> same 10 fps on the device.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1352631
>
> Title:
> support accelerated_2d_canvas
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oxide/+bug/1352631/+subscriptions
>

Revision history for this message
Justin McPherson (justinmcp) wrote :

By forcing the use of the accelerated 2d canvas (via settings->setAccerlerated2dfCanvasEnabled(true); in render_view_impl.cc), I've had positive results; with frame rates over 40, maybe 50 average.

This is on a Nexus 4.

David Barth (dbarth)
Changed in oxide:
status: New → Triaged
Revision history for this message
David Barth (dbarth) wrote :

Further testing by Chris indicates that Krillin can also support the same accelerated 2d canvas feature.

Revision history for this message
David Barth (dbarth) wrote :

A build is now available in https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/ for people interested in testing.
On N4, I can get a solid 40FPS most of the time, with up to 57FPS at times.

David Barth (dbarth)
Changed in oxide:
status: Triaged → In Progress
Changed in oxide:
milestone: none → branch-1.3
status: In Progress → Fix Released
assignee: nobody → Justin McPherson (justinmcp)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.