Infeasible
Status Update
Comments
kg...@gmail.com <kg...@gmail.com> #2
The problem is very serious.
Currently html5 clearRect isn't working within any android 4 devices.
Please, solve this problem as soon as possible.
Currently html5 clearRect isn't working within any android 4 devices.
Please, solve this problem as soon as possible.
kg...@gmail.com <kg...@gmail.com> #3
we have the same problem
We are waiting for a patch since November because none of the workaround we have tried is stable.
We hope that the patch will come before the launching of our app and if not...well, sadly, we will launch the app on iOS and windows only
We are waiting for a patch since November because none of the workaround we have tried is stable.
We hope that the patch will come before the launching of our app and if not...well, sadly, we will launch the app on iOS and windows only
kg...@gmail.com <kg...@gmail.com> #4
[Comment deleted]
xa...@android.com <xa...@android.com>
kg...@gmail.com <kg...@gmail.com> #5
Still appears to be an issue as I'm getting quirky results when trying clearRect in a loop. #3 solution is good but too heavy to work in a loop.
[Deleted User] <[Deleted User]> #6
What about using requestAnimationFrame for loop rather than using a timer loop ?
yr...@google.com <yr...@google.com> #7
Hey, this is a serious issue that is affecting our production components, could someone please look into this???
kg...@gmail.com <kg...@gmail.com> #8
is there any solvtion for that issue ?
yr...@google.com <yr...@google.com> #9
Something like that works for me:
function bug_workaround() {
$(canvas).hide();
setTimeout(function() {
$(canvas).show();
}, 1);
}
I call this function after clear.
function bug_workaround() {
$(canvas).hide();
setTimeout(function() {
$(canvas).show();
}, 1);
}
I call this function after clear.
ma...@gmail.com <ma...@gmail.com> #10
Opacity trick is better because will not initiate page reflow and hide /
show will.
show will.
in...@mobileparadigm.co.uk <in...@mobileparadigm.co.uk> #11
which trick would that be? modify the opacity?
sm...@gmail.com <sm...@gmail.com> #12
Yes,
function bug_workaround() {
canvas.style.opacity = 0.99;
setTimeout(function() {
canvas.style.opacity = 1;
}, 1);
}
function bug_workaround() {
canvas.style.opacity = 0.99;
setTimeout(function() {
canvas.style.opacity = 1;
}, 1);
}
sm...@gmail.com <sm...@gmail.com> #13
[Comment deleted]
Description
applicable)
Host OS: OS X
SDK tools version (available in the "About" section of the 'android' tool
UI): 23.0.2
Android Studio version: 0.8.9
STEPS TO REPRODUCE:
1. Build application requiring multiple dex files. Used example found here:
2. Observe app runs correctly on 4.x device.
3. Observe app crashes upon installation on gingerbread device.
EXPECTED RESULTS:
Multidex application runs on gingerbread device.
OBSERVED RESULTS:
Application causes dalvik crash on gingerbread devices:
E/dalvikvm( 2404): LinearAlloc exceeded capacity (8388608), last=6888
E/dalvikvm( 2404): VM aborting
F/libc ( 2404): Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1)
...
ADDITIONAL INFORMATION:
I've seen mentions but no definitive evidence that GB devices cannot load dex files over 5Gb. As an experiment I patched dx to produce smaller dex files (see attachement). Building with the modified dx program produced an APK with smaller (no larger than 3Mb) dex files and installation errors did not occur on gb devices.
Due to this I suspect that dx needs to either by default generate smaller dex files to ensure compatibility with gb devices or be tunable in the build configuration for app producers wishing to maintain compatibility with gb.