Assigned
Status Update
No update yet.
Comments
mv...@google.com
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.
il...@google.com
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
ch...@google.com
[Comment deleted]
an...@google.com
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.
il...@google.com
What about using requestAnimationFrame for loop rather than using a timer loop ?
ni...@hinge.co
Hey, this is a serious issue that is affecting our production components, could someone please look into this???
mr...@gmail.com
is there any solvtion for that issue ?
jb...@google.com
st...@gmail.com
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.
jb...@google.com
ap...@google.com
Opacity trick is better because will not initiate page reflow and hide /
show will.
show will.
ap...@google.com
which trick would that be? modify the opacity?
ap...@google.com
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);
}
ap...@google.com
[Comment deleted]
ap...@google.com
Hi,
I'm having the same problem but the workaround doesn't seem to help. Was wondering if this issue is somehow fixed by now?
Thank You.
I'm having the same problem but the workaround doesn't seem to help. Was wondering if this issue is somehow fixed by now?
Thank You.
ca...@gmail.com
This opacity hack works for me. I've had this issue on 4.1.1 and 4.1.2, both Galaxy S3 and the S3 mini.
Calling this function between clearing the canvas and the next draw call seems to have fixed the problem.
function bug_workaround() {
canvas.style.opacity = 0.99;
setTimeout(function() {
canvas.style.opacity = 1;
}, 1);
}
Thanks, dennis.ra!
Calling this function between clearing the canvas and the next draw call seems to have fixed the problem.
function bug_workaround() {
canvas.style.opacity = 0.99;
setTimeout(function() {
canvas.style.opacity = 1;
}, 1);
}
Thanks, dennis.ra!
il...@google.com
The opacity trick doesn't seem to work for me (Android 4.3).
Hide & show causes a lot of nasty flicker.
This solution works form me:
https://medium.com/@dhashvir/android-4-1-x-stock-browser-canvas-solution-ffcb939af758
But only the second one:
canvas.clearRect(0, 0, w, h);
canvas.style.display = 'none';// Detach from DOM
canvas.offsetHeight; // Force the detach
canvas.style.display = 'inherit'; // Reattach to DOM
Performance hit seems to be minimal for my app (game with multiple canvas one over another).
Hide & show causes a lot of nasty flicker.
This solution works form me:
But only the second one:
canvas.clearRect(0, 0, w, h);
canvas.style.display = 'none';// Detach from DOM
canvas.offsetHeight; // Force the detach
canvas.style.display = 'inherit'; // Reattach to DOM
Performance hit seems to be minimal for my app (game with multiple canvas one over another).
je...@pinkfroot.com
seems android 4.1/4.2/4.3 both have this problem?
il...@google.com
Re
Description
Component used: Navigation Version used: 2.5.3
Use Case
I would like to be able to incrementally migrate to Navigation Compose while migrating a Fragment View-based app to Compose.
Problem Statement
When migrating a Fragment View-based app that is using Navigation Component to Compose, it's not currently possible to incrementally migrate to Navigation Compose. Instead, all screens first need to be migrated to Compose and only then can apps migrate to Navigation Compose.
While this might work for smaller apps, this may not be feasible for apps with a lot of screens as the switch would be a pretty large change all at once. Additionally, new features or screens would still need to be wrapped inside a Fragment which is tech debt as the eventual goal is to remove fragments altogether. This experience can be improved by creating better interop between Fragment and Compose Navigation.
Possible Solution
Add a single Compose container fragment in the navigation graph. This container can then add new composable destinations to the existing XML navigation graph. This would also avoid new screens having to create new fragments altogether and migrated screens (composables) can then be incrementally added to the graph. Once all screens are in Compose, the switch to remove Fragment-based navigation should be a smaller change.