As everyone know, a lot of modern mobile application developed using HTML5. It's simple to port them on other devices with different system using native webview or for example PhoneGap, etc, etc.
iOs, webOs and others do not have any problems with HTML5, but Android 3.x - have one big problem:
Starting from 3.0 hardware acceleration presented for android devices - http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html
And if you use webview - it's not possible to play video or flash without hardware acceleration, it's enabled by default in native browser and other apps and in theory should increase performance. It look like everything is ok, but WHEN YOU ENABLE HARDWARE ACCELERATION - PERFORMANCE OF YOU HTML5 APP BECOME VERY POOR, 2-3 TIMES LESS THAN WITHOUT ACCELERATION.
Tested on 3.0, 3.1, different ROMs, 2x 7500 and 2x 7510 samsung devices and on 2x acer iconia tab a500.
Please check attachments:
test_hw_acc_enabled_3.1.apk - test application that show difference between two WebViews with hardware acceleration enabled and disabled. Top view - HA enabled (and very slow), bottom view - HA disabled (fast, but not so fast as we want because of no hardware acc.)
test_hw_acc_enabled_3.1.rar - android sources with html5/javascript page in assets (index.html).
Please note, that if you run this page in native browser that is pre-installed on Samsung Galaxy Tab 10.1 - you'll get same lags because HW acceleration enabled in this browser by default. So all Tegra 2 advantages lost here even in comparison with my 800mhz phone on Android 2.1.
No any 3rd-party libs or plugins used, here is small description:
Android sources:
AndroidManifest.xml :
enabling HW accell on application level
Code:
<application android:icon="@drawable/icon" android:label="@string/app_name" android:hardwareAccelerated="true" >
hw_webview.java:
Code:
final WebView myWebView_hw_acc_enabled = (WebView) findViewById(R.id.webView1);
WebSettings webSettings1 = myWebView_hw_acc_enabled.getSettings();
webSettings1.setJavaScriptEnabled(true);
myWebView_hw_acc_enabled.setWebChromeClient(new WebChromeClient());
//enable hardware acceleration for the 1st view, this line can be skipped
//as acceleration enabled on application level by AndroidManifest.xml
myWebView_hw_acc_enabled.setLayerType(WebView.LAYER_TYPE_HARDWARE, null);
myWebView_hw_acc_enabled.loadUrl("file:///android_asset/www/index.html");
final WebView myWebView_hw_acc_disabled = (WebView) findViewById(R.id.webView2);
WebSettings webSettings2 = myWebView_hw_acc_disabled.getSettings();
webSettings2.setJavaScriptEnabled(true);
myWebView_hw_acc_disabled.setWebChromeClient(new WebChromeClient());
//disable hardware acceleration for the 2nd view
myWebView_hw_acc_disabled.setLayerType(WebView.LAYER_TYPE_SOFTWARE, null);
myWebView_hw_acc_disabled.loadUrl("file:///android_asset/www/index.html");
index.html - simple setInterval used with 60fps estimate (move by 1px every 15 ms), with additional plugins (example:jQuery.animate) or libs we have much more lags:
Code:
<div id="box" style="left:50px;top:50px;width:150px;height:100px;position:absolute;background:#000;"></div>
<script>
var left = 50; //initial position
var delta = 1; //pixels per iteration
var dir = 1; // direction 1/-1
function move()
{
var div = document.getElementById('box'); //get box
if ((left>500)||(left<50)) dir = dir * -1; //change direction
left = left + delta*dir; //change position
div.style.left = left+'px'; //update style with new position
}
setInterval("move()",15); //every 15ms - 60fps estimate
</script>
Example is only for simple html and javascript, but other modern features like CSS transitions, etc - have same problem.
Any idea how to fix this? I need HA enabled with expected performance increased but not decreased. As far as I understand - this is very big problem for android 3.0, because HTML5 is very popular and qty of HTML5 mobile application will only grow. Note that other modile systems work correctly (even 1st ipad and my motorola defy faster in HTML5 than overclocked honeycomb tegra 2 device)
I wonder if its because of the actual drivers being used. Is the video driver used by the kernel compiled in or insmod loaded during boot? I really havnt looked at how each driver is loaded in regards to Tegra 2 SOC.
Super wishful thinking would hope that maybe nVidia has a newer driver we could slap down and benchmark with HW accelleration?
Also... On my Tab with the test apk you made, two webviews actually start out at the same speed then the hardware accellerated one begins to lag at roughly 2 seconds into the movement across.
It never regains that same speed as the non accellerated view so its not likely a GC running/inducing issue as it would likely speed up after the GC event (assuming it doesnt cause continous calls to the garabage collector).
3.2?
any new ideas?
may be someone can run attached application on tablet with android 3.2 - just to check if bug fixed?
tested on acer iconia tab with 3.2 - same problem ;(
I tested this on Asus Transformer TF101 (Andoid 3.2.1) and the issue exists there too.
Tested on Samsung galaxy tab 10.1. Same problem
Sent from my GT-P7500 using Tapatalk
Anyone have benchmarked accelerated webview performance of Android 4.0?
Same problem here and with Android 4 on Galaxy Nexus,
android hardware acceleration is something that works bad and the problem is that they don't have fixed it yet.
sblantipodi said:
Same problem here and with Android 4 on Galaxy Nexus,
android hardware acceleration is something that works bad and the problem is that they don't have fixed it yet.
Click to expand...
Click to collapse
Damn, hate it when I accidentally hit the "thanks" button...
BTW- this thread is 1) long dead, 2) discussing android 3.1 on a tablet, not android 4.0 on a phone.
slack04 said:
Damn, hate it when I accidentally hit the "thanks" button...
BTW- this thread is 1) long dead, 2) discussing android 3.1 on a tablet, not android 4.0 on a phone.
Click to expand...
Click to collapse
Is this thread expired?
I saied that I have the same problem on the tablet and on the android 4 device.
I know I'm late to this thread but the way you are doing your move is wrong. When you do DOM manipulation (by setting left/right) you force a repaint, which means you get none of the benefits of hardware acceleration and all of the downsides. You need to use CSS 3D transforms instead, which allows the browser to avoid repainting entirely making it silky smooth as a result.
This app allows you to switch the hertz of your display. This is a tool for advanced users, please read this entire description. Hopefully this app will be obsolete sooner rather than later.
If you have a compatible TV or monitor, you may want to view specific content on a different hz. Apps can actually switch the hz used by your device. This feature is new to Android, and thus very few apps support it yet, which is the main reason an app like this one can come in handy.
Unfortunately, at the time of this writing, even if developers added this functionality to their apps (devs: check preferredRefreshRate in WindowManager.LayoutParams), it may not work right or at all. There are several issues with Google's current implementation, as it exists on the Nexus Player, firmware LRX21V:
- The available modes appear to only be detected on Android TV boot. This means your TV or receiver needs to be turned on and switched to the correct input before booting the Android TV device, or not all the modes your TV supports will be recognized.
- Switching hz may break audio. This app provides an option to fix that, but that does require your device to be rooted. Note that this may be both Android TV device as well TV dependent - your setup may not display this issue.
- Switching hz may randomly reboot the device
- The Android API lies. It'll happily report the current refresh rate to be X hz while it is actually Y hz, which may cause timing issues for video apps that actually take refresh rate into account.
- There is no hz override in display settings
So, until these things are fixed Google-side - and it would actually start to make sense for developers to include the functionality in their apps - at least you can play around with this.
Note that 'forcing' a certain hz might be wording it too strong. Android is still free to ignore the setting, and if an app really wanted to, it could override it as well.
Disclaimer: works for me, provided as-is, this app has no support, the situation describe above may change at any time
Why?
I was looking at committing this feature into xbmc/kodi, so I built a quick proof-of-concept app first, as I has not used the API before. During testing I quickly noted that the API doesn't work reliably enough yet to be part of that project.
Download
Google Play (this link is pending Play cache update and Play team approval)
Gonna be a bit off-topic here, sorry about that.
I don't have a Nexus Player, but changing the external display's refresh rate was one of the features I wanted for a long time, it was the last missing thing to have a nice, smooth movie playback experience in an app like xbmc/kodi.
How device-dependent is this app? Can I use it on a N5 for instance? (or a Chromecast?) It has power to pretty much play any video file, it has an 1080p display and can send 1080p through hdmi, so a ~24 hz refresh rate for movies is all that's missing.
It's nice to see Android itself supporting this (even if it currently broken as you say).
What about the external display's modes or the external display's resolution, can they also be changed? The other problem for a good movie experience is with devices not having an exact 1080p display (like the N7 2013). Since the external display is always mirrored (and not extended), the device's 1920*1200 image will be shrunk to the TV's 1920*1080 screen leaving black bars on the sides which really sucks. I've seen some root-required hacks for the N7 2013 to force a standard 1080p resolution, but that's not a real solution... It would be nice to have these sorted out, because until that, even a Raspberry Pi provides a way superior movie-experience than pretty much any Android-powered stuff...
Will this work on the ADT-1?
What about 120Hz TVs?
I dont see 120Hz in the selection is that because of some limitation?
scorpeeon said:
Gonna be a bit off-topic here, sorry about that.
I don't have a Nexus Player, but changing the external display's refresh rate was one of the features I wanted for a long time, it was the last missing thing to have a nice, smooth movie playback experience in an app like xbmc/kodi.
How device-dependent is this app? Can I use it on a N5 for instance? (or a Chromecast?) It has power to pretty much play any video file, it has an 1080p display and can send 1080p through hdmi, so a ~24 hz refresh rate for movies is all that's missing.
It's nice to see Android itself supporting this (even if it currently broken as you say).
What about the external display's modes or the external display's resolution, can they also be changed? The other problem for a good movie experience is with devices not having an exact 1080p display (like the N7 2013). Since the external display is always mirrored (and not extended), the device's 1920*1200 image will be shrunk to the TV's 1920*1080 screen leaving black bars on the sides which really sucks. I've seen some root-required hacks for the N7 2013 to force a standard 1080p resolution, but that's not a real solution... It would be nice to have these sorted out, because until that, even a Raspberry Pi provides a way superior movie-experience than pretty much any Android-powered stuff...
Click to expand...
Click to collapse
First, this app is written only with the main display in mind. As such, it won't work for external displays as it seems you are after. It won't work on an N5 or N7 either as this incarnation of the app only has a TV interface. It won't run on a Chromecast, because that doesn't actually run Android apps. Also, I'm pretty sure the main screens of the N5 and N7 only support 60hz.
That being said, and I have never tried this myself (I really should get a mini-HDMI cable to I can play with this stuff), so take this with a big grain of salt, but from what I've seen and read, the scaling and mirroring you mention is app-based. The Android API does provide mechanisms to display content in the full resolution of the external display (since API 17), but the app requires (potentially a lot of) extra code to do this. The mirroring (and thus auto-scaling) is merely the default thing Android does when an app does not override that behavior. Quickly checking the API docs, it also appears to be possible to adjust the hz of the secondary display in the same way (since API 21). However, again, the currently active app is the one who must control this.
TVHZ uses a trick to get around the restriction of having to be the currently active app. It does not appear this trick can be used the same way to control the hz of an external screen, through the regular API. This does not necessarily mean it isn't possible (without root), it just means more investigation would be required to know for sure.
xamadeix said:
Will this work on the ADT-1?
Click to expand...
Click to collapse
I have not tried.
the_mentor said:
What about 120Hz TVs?
I dont see 120Hz in the selection is that because of some limitation?
Click to expand...
Click to collapse
No. 120hz is display panel refresh rate, not an input refresh rate. Don't worry about it
With stuff like this the rule is pretty much, if you don't know why you would change it and what you would change it to, you're probably best off with the default (unless someone specifically tells you otherwise).
Chainfire said:
First, this app is written only with the main display in mind. As such, it won't work for external displays as it seems you are after. It won't work on an N5 or N7 either as this incarnation of the app only has a TV interface. It won't run on a Chromecast, because that doesn't actually run Android apps. Also, I'm pretty sure the main screens of the N5 and N7 only support 60hz.
That being said, and I have never tried this myself (I really should get a mini-HDMI cable to I can play with this stuff), so take this with a big grain of salt, but from what I've seen and read, the scaling and mirroring you mention is app-based. The Android API does provide mechanisms to display content in the full resolution of the external display (since API 17), but the app requires (potentially a lot of) extra code to do this. The mirroring (and thus auto-scaling) is merely the default thing Android does when an app does not override that behavior. Quickly checking the API docs, it also appears to be possible to adjust the hz of the secondary display in the same way (since API 21). However, again, the currently active app is the one who must control this.
TVHZ uses a trick to get around the restriction of having to be the currently active app. It does not appear this trick can be used the same way to control the hz of an external screen, through the regular API. This does not necessarily mean it isn't possible (without root), it just means more investigation would be required to know for sure.
I have not tried.
Click to expand...
Click to collapse
This is amazing.. Will it work on a ouya do you think?
Chainfire said:
This app allows you to switch the hertz of your display. This is a tool for advanced users, please read this entire description. Hopefully this app will be obsolete sooner rather than later.
If you have a compatible TV or monitor, you may want to view specific content on a different hz. Apps can actually switch the hz used by your device. This feature is new to Android, and thus very few apps support it yet, which is the main reason an app like this one can come in handy.
Unfortunately, at the time of this writing, even if developers added this functionality to their apps (devs: check preferredRefreshRate in WindowManager.LayoutParams), it may not work right or at all. There are several issues with Google's current implementation, as it exists on the Nexus Player, firmware LRX21V:
- The available modes appear to only be detected on Android TV boot. This means your TV or receiver needs to be turned on and switched to the correct input before booting the Android TV device, or not all the modes your TV supports will be recognized.
- Switching hz may break audio. This app provides an option to fix that, but that does require your device to be rooted. Note that this may be both Android TV device as well TV dependent - your setup may not display this issue.
- Switching hz may randomly reboot the device
- The Android API lies. It'll happily report the current refresh rate to be X hz while it is actually Y hz, which may cause timing issues for video apps that actually take refresh rate into account.
- There is no hz override in display settings
So, until these things are fixed Google-side - and it would actually start to make sense for developers to include the functionality in their apps - at least you can play around with this.
Note that 'forcing' a certain hz might be wording it too strong. Android is still free to ignore the setting, and if an app really wanted to, it could override it as well.
Disclaimer: works for me, provided as-is, this app has no support, the situation describe above may change at any time
Why?
I was looking at committing this feature into xbmc/kodi, so I built a quick proof-of-concept app first, as I has not used the API before. During testing I quickly noted that the API doesn't work reliably enough yet to be part of that project.
Download
Google Play (this link is pending Play cache update and Play team approval)
Click to expand...
Click to collapse
Good job man, thanks for developing for the nexus player
Absolutely awesome!
Hopefully this will work for the Amazon Fire TV in the future too!
Chainfire said:
I was looking at committing this feature into xbmc/kodi, so I built a quick proof-of-concept app first, as I has not used the API before. During testing I quickly noted that the API doesn't work reliably enough yet to be part of that project.
Click to expand...
Click to collapse
FYI, I've also dabbled with refresh rate switching with Kodi, very WIP code (i.e. full of commented trial-and-error code ) is at https://github.com/anssih/xbmc/commits/android/refreshrate_wip (2 commits).
I also noticed the audio breaking (haven't investigated further yet), but I didn't see any reboots occurring.
If I remember correctly, this did not work on ADT-1 last I tested.
dsfdfsdfs said:
FYI, I've also dabbled with refresh rate switching with Kodi, very WIP code (i.e. full of commented trial-and-error code ) is at https://github.com/anssih/xbmc/commits/android/refreshrate_wip (2 commits).
I also noticed the audio breaking (haven't investigated further yet), but I didn't see any reboots occurring.
If I remember correctly, this did not work on ADT-1 last I tested.
Click to expand...
Click to collapse
The audio breakage occurs in device-specific code, so it may not happen on different devices. On the other hand, it may have been an oversight in the Android framework itself that many TVs will disconnect the audio channel as well when switching hz's - in essence completely severing the connection and building it up again.
Fixing the audio can be done by manually killing /system/bin/mediaserver (it is automatically restarted after a few seconds), or calling "stop media && start media". As a side effect this may actually crash apps using audio (or video) at that time, so actually doing this at the start of a video is not really an option - even if it didn't require root and wasn't device-specific.
The reboot is rare, but I've switched hz's a couple of hundred times now, and it does happen.
Glad to see someone else is looking at this though, if you put it in Kodi (when it actually works) that means I won't have to
Chainfire said:
The audio breakage occurs in device-specific code, so it may not happen on different devices. On the other hand, it may have been an oversight in the Android framework itself that many TVs will disconnect the audio channel as well when switching hz's - in essence completely severing the connection and building it up again.
Click to expand...
Click to collapse
Sorry, by "not working on ADT-1" I meant that the refresh rate switching wasn't working there.
Anyway, the HDMI audio stuff is one-way communication (except for EDID, which can't be "disconnected" in that sense), so there is no "disconnecting the audio channel" from the TV side.
Chainfire said:
Fixing the audio can be done by manually killing /system/bin/mediaserver (it is automatically restarted after a few seconds), or calling "stop media && start media". As a side effect this may actually crash apps using audio (or video) at that time, so actually doing this at the start of a video is not really an option - even if it didn't require root and wasn't device-specific.
The reboot is rare, but I've switched hz's a couple of hundred times now, and it does happen.
Glad to see someone else is looking at this though, if you put it in Kodi (when it actually works) that means I won't have to
Click to expand...
Click to collapse
Argh, and I was thinking the opposite here But yeah, I'll work on it as long as time permits.
Have you reported the audio/reboot issues to Google yet?
dsfdfsdfs said:
Sorry, by "not working on ADT-1" I meant that the refresh rate switching wasn't working there.
Click to expand...
Click to collapse
I wasn't implying it might work on any specific device, just that at least the log spam from the audio issue come from a fugu-specific driver, a different driver may behave differently, or not if it's really a framework issue. Anyway, we're knee-deep in speculation here, it matters not.
Anyway, the HDMI audio stuff is one-way communication (except for EDID, which can't be "disconnected" in that sense), so there is no "disconnecting the audio channel" from the TV side.
Click to expand...
Click to collapse
I'll admit I know nothing about these things, but if the TV cuts all power to the port, wouldn't the device 'sense' that and possibly interpret that as a disconnect?
Argh, and I was thinking the opposite here But yeah, I'll work on it as long as time permits.
Click to expand...
Click to collapse
Maybe my test videos weren't great, but I didn't think things looked noticably better at 24hz than they did at 60hz. Though admittedly that may be related to the renderer not actually knowing the display is at 24hz. It was more of an experiment for me than that I truly need it - I have some other issues to figure out with my NP that have higher priority.
Have you reported the audio/reboot issues to Google yet?
Click to expand...
Click to collapse
Nope, because I have not had the time (or will) to produce a decent error report yet.
Chainfire said:
I'll admit I know nothing about these things, but if the TV cuts all power to the port, wouldn't the device 'sense' that and possibly interpret that as a disconnect?
Click to expand...
Click to collapse
Yeah, though I'd be somewhat surprised if that happens - if the source device sees a disconnect/reconnect, it may consider the to be a "new device" and do all sorts of enumeration... but anyway, as you said, pointless to speculate really
Chainfire said:
Maybe my test videos weren't great, but I didn't think things looked noticably better at 24hz than they did at 60hz. Though admittedly that may be related to the renderer not actually knowing the display is at 24hz. It was more of an experiment for me than that I truly need it - I have some other issues to figure out with my NP that have higher priority.
Click to expand...
Click to collapse
Yeah, I too have a hard time seeing the 24/60Hz difference with most videos - not immediately sure if renderer thinking it was 60Hz could cause visible issues, though. With 25/50p European TV footage the 50/60Hz difference is more pronounced.
Chainfire said:
Nope, because I have not had the time (or will) to produce a decent error report yet.
Click to expand...
Click to collapse
OK. I'll probably make one after I've had the time to gather some more data/info.
Update?
Can anyone update me on the current status of frame rate switching for android tv, specifically within Kodi? I'm hoping by the time the Shield console comes out I will be able to playback movies at 24hz.
anyone? I've searched around and haven't been able to find if this has been officially implemented in any apps.
Chainfire said:
This app allows you to switch the hertz of your display.
Click to expand...
Click to collapse
Will your tool conflict with modes that are built in to integrated Android TVs, such as the forthcoming Sonys?
please get 24hz working on the Shield Tv
This is now finally implemented in Kodi (version 15.0 Beta 2, on Google Play, formerly XBMC). It works in at least Nexus Player and Shield TV, but should work in any Android system that supports refresh rate switching. You need to enable automatic refresh rate switching in the Kodi video settings.
I wrote the support back in December, but the problems mentioned in this thread prevented putting it in officially until now. Those issues seem to have been resolved in the Android versions released since then.
Works, somehow
The app does it job, although it seems to reset to 60Hz at reboot (even with the option set to keep at reboot).
Now, I agree, Google should set the output Hz to match the video stream at hand. Yes, it will be a short blackout, but so what!?.
Thanks for the app. I'm running it on the latest 6.0 available today.
This is sort of a research thread and I hope someone here is willing to weigh in with their knowledge.
I'm a Ruby / Java / Python / JS / PHP developer, who did a little bit of Android game development during my studies back in 2012. I assume things have changed since then.
I'm working on a commercial project where we need a network controllable video player for LED TV's and/or video projectors. Currently, we are using a Raspberry Pi 3-based design with the OMX Player, but this board is somewhat weak and the player is cumbersome to interact with and has limitations. Especially when it comes to rendering multiple layers with transparency. I would like to work on a platform where I have a rich multimedia API for rendering sound and video with an object-oriented API.
I have obtained myself an Asus Tinker, which has an official Android distribution. This runs rather smooth and from what I can tell, the API's for Android appear rich and flexible. So my questions are:
1) Is it possible to develop a launcher / kiosk app, that will allow me to boot into a "blank" screen and allow the app to place video surfaces, image surfaces and text layers? I should also be able to interact with the sound card and playback PCM audio. I would like an API that supports audio mixing, amplification, etc... There is no direct user input on the device, so I will need a solution that does not present any status bars, google account wizards, wifi wizards, update prompts, notifications or anything. In fact, when the Tinker is powered on, there should ideally not be anything indicating that it's Android.
I guess what I'm asking for is kind of a console video game engine / SDK, minus game controller support.
2) What kind of libraries or API's would I need to dive into and understand? Where should I start?
3) How complex is it? What is the scope of it? How much development time? Days? Weeks? Months? Years? Would I need more developers with specific skills?
4) Is there any developer here who's interested in participating in such a project as a paid freelance developer?
5) Is there any alternative software/OS platforms I should look into? I want to be able to boot into a custom passive user interface that is remotely controlled over REST by another device. I would like to avoid dealing with low level implementation of video decoding and rendering, but at the same time I would prefer to have control over screen resolution, refresh rate, color depth and I would like to run a ssh server on the client, so it can be serviced. Ideally, the platform should be able to both stream from the internet, but also accept commands to download to local storage and play from there.
6) Is there any alternative hardware platform I should look into?
7) Anything else I should consider? Problems that I'll need to address / prepare for?