Skip to content

Do not change the Android layer types (hardware/software) #4625

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

Merged
merged 1 commit into from
Aug 25, 2017

Conversation

PanayotCankov
Copy link
Contributor

I don't know why we did this in the first place,
but changing the rendering mode can not be good.
Let's re-run all possible UI tests.

@ghost ghost assigned PanayotCankov Jul 31, 2017
@PanayotCankov PanayotCankov added this to the 3.2 milestone Jul 31, 2017
@PanayotCankov PanayotCankov added ready for test TSC needs to test this and confirm against live production apps and automated test suites and removed in progress labels Jul 31, 2017
@PanayotCankov
Copy link
Contributor Author

run ci

@NathanaelA

This comment was marked as abuse.

@PanayotCankov
Copy link
Contributor Author

PanayotCankov commented Aug 3, 2017

Yea, I read that,

A little while ago I removed some of the ops that were clipping images. Clipping with paths were not applying antialiasing on the images so they looked terrible anyway. Containers may not clip content when with rounded corners but that would be rarely a problem.

In general I think we should not mess internally with the rendering mode. "Hardware acceleration is enabled by default if your Target API level is >=14" and we will now never set it to software, so layers instead of forced to software every once in a while by {N}, should stay hardware all the time.

Now since we do not enable/disable hardware acceleration I think you can control it (e.g. on the windows) and it will be inherited by the views down the hierarchy. Or at least you can use the <application android:hardwareAccelerated="true"> mentioned in the article you refer and the {N} won't mess with it.

Can you actually try the next versions of the widgets and the tns-core-modules in your app and verify that there is a performance hit?

@hshristov
Copy link
Contributor

run ci

1 similar comment
@SvetoslavTsenov
Copy link
Contributor

run ci

@SvetoslavTsenov
Copy link
Contributor

run android

@dtopuzov
Copy link
Contributor

run ci

@SvetoslavTsenov
Copy link
Contributor

Hey, @PanayotCankov could try to rebase this pull request.

@bradmartin
Copy link
Contributor

At one time, I think Enchev and I went back and forth on fixing an Android issue and it required changing the layer type. I can't recall the specifics, it was probably in late 2015 when I was working on some initial plugins for android components but something didn't work and we started stumbling on the layer types. If I find it, I'll drop a link. This might be totally unrelated but just wanted to throw it out there 😄

@bradmartin
Copy link
Contributor

Ah so it was @vakrilov who helped, Enchev just cleaned up 👍
#830 (comment)

@PanayotCankov
Copy link
Contributor Author

@bradmartin I think before we relied on Canvas clipping to round the button, and clipping was not antialiased and was not working properly on some devices, unless software mode is set. I think I prefer to keep the defaults now since the geometry is drawn for the button background using different Canvas APIs. If the issue reoccur, I'd like to rather provide a property on the view to control the rendering mode.

@PanayotCankov PanayotCankov force-pushed the android-no-layer-modes branch from d1d3a19 to c80235d Compare August 24, 2017 08:57
@SvetoslavTsenov
Copy link
Contributor

uitests

@SvetoslavTsenov
Copy link
Contributor

animations

@PanayotCankov PanayotCankov merged commit d62df37 into master Aug 25, 2017
@ghost ghost removed the ready for test TSC needs to test this and confirm against live production apps and automated test suites label Aug 25, 2017
@hshristov hshristov deleted the android-no-layer-modes branch August 25, 2017 08:15
@lock
Copy link

lock bot commented Aug 27, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Aug 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants