Bugs with android:hardwareAccelerated="true" in API level 11+

[GoogleCodeExporter]

What steps will reproduce the problem?
1. add  android:hardwareAccelerated="true" to application manifest
2. run achartengine demo 0.6.0
3. zoom close into various XYSeries-based-charts
4. Note that lines dissapear

What is the expected output? What do you see instead?
Same behavior as in software rendering mode, just slightly more fluid

Please provide a source code snippet that we can use to replicate the issue.
demo.

What version of the product binary library are you using?
0.6.0

Please provide any additional information below.

Xoom

Original issue reported on code.google.com by jondwil...@gmail.com on 1 Mar 2011 at 8:00

[GoogleCodeExporter]

Original comment by dandrome...@gmail.com on 30 Mar 2011 at 7:59

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by dandrome...@gmail.com on 1 Jul 2011 at 7:12

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

I tested this with Android 3.0 in the emulator and I cannot replicate it.
Please provide extra info.

Original comment by dandrome...@gmail.com on 4 Jul 2011 at 7:27

[GoogleCodeExporter]

Closing this as no new feedback at all.

Original comment by dandrome...@gmail.com on 16 Jul 2011 at 7:48

• Changed state: Verified

[GoogleCodeExporter]

Actually I've got the same issue on my tablet.
If I enable hardware acceleration, the line chart dissapears when you zoom in. 
It works fine when I disable the acceleration, but
1) I need it :)
2) When it's off, the chart's panning becomes visibly jerky!

What do you need me to provide to help you fix the issue? :)

Original comment by artiom....@gmail.com on 24 Jul 2011 at 10:43

[GoogleCodeExporter]

Same issue here on ASUS EeePad Transformer. I think this is due to the fact 
that hardware acceleration is still lacking and needs more tuning. More 
information can be found here:
http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.
html

As a work-around, it's possible to disable hardware acceleration on the chart 
view using View.setLayerType(View.LAYER_TYPE_SOFTWARE, null), while keeping it 
enabled for the whole application.

Please note that this cannot be replicated on the emulator because it doesn't 
support hardware acceleration (so far).

Original comment by majed.al...@gmail.com on 30 Sep 2011 at 2:41

[GoogleCodeExporter]

Original comment by dandrome...@gmail.com on 20 Oct 2011 at 6:38

• Changed state: New

[GoogleCodeExporter]

Is there any estimate for when this will be fixed? Seems like I can't even show 
10 days worth of data on the chart, as it just disappears from the screen, and 
my users are complaining constantly :)

I'm happy to provide any help in fixing this issue. I've tried to go through 
the code, and debug it to try find out what happens, but haven't found anything 
so far (partially since I don't know your code :P ), but I'm sure there should 
be a rather simple fix somewhere, and I'm happy to help fix/debug it if 
necessary. Just need some help and direction

Updates please?

Original comment by artiom....@gmail.com on 25 Oct 2011 at 4:33

[GoogleCodeExporter]

No estimates at all.
I don't have a device with hardware acceleration to test on.

Have you tried to get the ACE source code and try the suggestion at comment 6?

Original comment by dandrome...@gmail.com on 26 Oct 2011 at 5:47

[GoogleCodeExporter]

Actually, there's no need to use the ACE source code to use that suggestion. 
I've forgotten about it, and I guess it'll work as a workaround for now, until 
this is fixed.

Is there any way I can help with fixing this issue?
I've already got the source (my app actually builds against a modified version 
of ACE at the moment, I've made some improvements to the Time chart's grid), 
and I've familiarized myself with some of the classes and structures there

Original comment by artiom....@gmail.com on 26 Oct 2011 at 7:15

[GoogleCodeExporter]

Here's a patch for achartengine that disables hardware acceleration. It would 
be awesome if this patch gets included so that if/when this acceleration 
problem gets fixed, achartengine can simply release a new version, instead of 
asking all users of the project to comment out their lines disabling 
acceleration for achartengine views.

Original comment by candrews...@gmail.com on 10 Nov 2011 at 9:07

Attachments:

• disableAcceleration.diff

[GoogleCodeExporter]

While the developers may not have an Android 3 device (not the emulator), it's 
still quite bad to completely ignore such an issue. Especially since there is 
information out there about how HW acceleration affects rendering, and there 
are users here that would be willing to test changes! (like me, or others 
subscribed to this issue)..

To the devs: Please read this article, and check at which point is your app 
using some of the methods not supported in HW mode, and which parts may be 
optimised
http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.
html

Original comment by artiom....@gmail.com on 12 Nov 2011 at 12:29

[GoogleCodeExporter]

I have not added android:hardwareAccelerated="true" to my application manifest 
but the app freezes on 3.2 devices. My question is if what you say in this page 
has any to do with why my app freezes even though I don't use this option in my 
manifest file. 

Original comment by ejcdevel...@gmail.com on 13 Nov 2011 at 9:39

[GoogleCodeExporter]

Did you check the stack trace to see when exactly it hangs, and which code 
causes it?
The missing, invisible elements is a known thing with hardware acceleration. 
Actual hanging - no, that seems to be an entirely different issue altogether...

Original comment by artiom....@gmail.com on 13 Nov 2011 at 11:03

[GoogleCodeExporter]

Right now I have not received any stack trace file from the Market. I have been 
unable to reproduce the error in the simulator. I just asked a user with this 
problem to send a report of it.

Original comment by ejcdevel...@gmail.com on 15 Nov 2011 at 9:24

[GoogleCodeExporter]

This issue is related to issue #47. In the hardware accelerated mode drawing 
offscreen is limited. When the points are to far away from each other it 
exceeds the hardware texture size so that the path couldn't be drawn. The first 
step to solve this issue is to apply a patch from issue #47 so that only 
visible points are drawn. The second task to enable hardware acceleration is to 
adapt the points for drawing when you zoom so that they aren't so far away from 
each and therefore not exceed the display buffer. I haven't taken a deeper look 
at issue #47 but I wrote down some equations for the second task which 
calculate the intersection points with the screen but I personally think that 
implementation is currently not possible because the points to be drawn have to 
be reduced first. Correct me if I'm wrong.

Original comment by timpam...@gmail.com on 27 Nov 2011 at 8:05

[GoogleCodeExporter]

Here is the patch to support hardware accelerated rendering. With this patch 
only the segments of the lines that are viewable will be drawn so that we don't 
draw of the screen. I recommend to apply the patch that I posted in issue #47. 
This patch speeds up software rendering as well. It's running with 20000 points 
fluently in software and hardware rendering mode.
I also attach a precompiled jar with the patch in issue #47 and my patch 
applied.

Original comment by timpam...@gmail.com on 27 Nov 2011 at 3:34

Attachments:

• achartengine-opengl-fix.patch
• achartengine-opengl.jar

[GoogleCodeExporter]

SVN rev. 319 includes this patch.
This looks like another great contribution. Thanks!

Original comment by dandrome...@gmail.com on 10 Dec 2011 at 2:33

• Changed state: Fixed

[GoogleCodeExporter]

I find that this patch draws the lines correctly, but if 
XYSeriesRenderer.setFillBelowLine(true) is set, then the fill is not drawn 
correctly. Attached an example screenshot.

I'm not sure if this is because of some other modification I've made. Can 
anyone else reproduce this?

Original comment by jondwil...@gmail.com on 10 Dec 2011 at 7:07

Attachments:

• device-2011-12-10-140643.png