Add scroll handling in onDraw() function of AwContents Class in Android_... #6
Conversation
|
Scrolling works like charm, thank you! |
|
It does work, but is extremely slow (feels like ~0.5 fps) on my Nexus 10. Is this simply because we don't have hardware acceleration implemented? ( |
|
Sorry I fell behind... this will definitely get merged. I'm trying to think if there's a way to make sure I don't overwrite the patch in future updates, since this file gets overwritten with the latest version in the Chromium tree whenever I update the build. |
|
👍 |
|
This patch no longer works with latest Chromium source. They have changed a number of things about |
|
I spent some time trying to get a new build going. They have some scrolling-related code in, and it almost works. Unfortunately, the build crashes when trying to input text in a field, due to missing resources. This is due to a hack that I did to get everything going quickly. I am trying to pull the correct resources from the Chromium tree now, and I'll post a new build when I have it. |
|
Hi Victor, I do have the latest Chromium build working, and I'm debugging the scrolling code right now. If you want, you can clone my fork of your repo, and try that -- will save you some time building it yourself. It represents the latest code as of Friday https://github.com/davisford/chromeview The viewport seems to respond a little bit to scroll events, it kind of bounces like it wants to scroll, but something just isn't right. This is my first foray into the Android + Chromium source, so I'm not as familiar with it and still learning my way around this behemoth. |
|
@davisford were you able to get the org.chromium.ui resources integrated? Without them, I get an autofill-related crash when typing text in an . |
|
Ah yes, I had to copy another R.java file over. Adding this to your update.sh script should fix it -- if not let me know. Maybe there's another breaking change since last Friday, but this all worked on Friday. Autofill also does seem to work for me, but I went into the Chrome settings and explicitly disabled it, b/c I find it annoying -- slow response / jarring UI. Otherwise, it does function for me, however. |
|
Here's the current source from Pasted here for posterity: public void onDraw(Canvas canvas) {
if (mNativeAwContents == 0) return;
mScrollOffsetManager.syncScrollOffsetFromOnDraw();
canvas.getClipBounds(mClipBoundsTemporary);
if (!nativeOnDraw(mNativeAwContents, canvas, canvas.isHardwareAccelerated(),
mContainerView.getScrollX(), mContainerView.getScrollY(),
mClipBoundsTemporary.left, mClipBoundsTemporary.top,
mClipBoundsTemporary.right, mClipBoundsTemporary.bottom )) {
Log.w(TAG, "nativeOnDraw failed; clearing to background color.");
int c = mContentViewCore.getBackgroundColor();
canvas.drawRGB(Color.red(c), Color.green(c), Color.blue(c));
}
}The problem seems to be that the calls to
|
|
small side remark on the rendering performance. using the android_webview_apk build target in chromium codebase will produce a test shell application that uses the libwebviewchromium. scrolling performance is very unsatisfying. i followed more or less the https://code.google.com/p/chromium/wiki/AndroidBuildInstructions but then... |
|
@mlasak are you saying that the content_shell doesn't have scrolling performance issues? i've been side-tracked with other issues the last couple days, but hope to get back to this soon. If you've resolved the problem in the latest code base, however, I'd love to see what you did. I've been testing both on the emulator as well as on a Galaxy Tab 10.1 |
|
@davisford yes, exactly! If you run the "ContentShell" application (http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=content/shell/android/shell_apk;hb=HEAD) you will experience a very good performance. It works perfectly on Samsung Galaxs S2 and S3 and as well on Asus Nexus 7 and probably on any other device as well. Scrolling is as fast as in Chrome itself. The "Android WebView Test Shell" (http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=android_webview/test/shell;hb=HEAD) on the other side is very slow and zoom / pinch do not work at all, plus changing the orientation will blank out the page. In the content shell approach the WebView compatibility is missing (i could live without that) but what is more serious: resources cannot be served from Android ContentProvider. (content:// scheme). What i do not understand is why there are two ways maintained to integrate the chromium core into Android apps and the one is unsuitable slow and the other comes with limited Android support. Running html5test.com in both applications will result with the same score (currently 428 +11 bonus on my S3), so the core seems to be the same but the integration and performance when interacting with the page differs a lot. |
|
@mlasak I will try that soon on my Galaxy Tab 10.1 -- thanks for the heads up. Do you happen to know what explicitly we lose when you mention that the "WebView compatibility is missing" ? Does this mean I can't add my own JavaScript <-> Java bridge APIs? What else do you lose out on? |
|
@davisford regarding WebView API compatibility, some parts are in deed missing . But after having another look on the ContentView and especially CoreViewCore (http://git.chromium.org/gitweb/?p=chromium.git;a=blob;f=content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java;hb=HEAD) it says that at least addJavascriptInterface would be available in the content shell based apps. Given that performance is not an issue, we should maybe try to wrap and integrate "content" instead AwContent. |
|
@pwnall + davisford - Guys, what's the status on building the latest Chromium? I'm thinking to have a check on the scrolling issue based on the latest chromium code base. Would be nice to have a working build to start with :).Thanks. |
|
@ziransun I had to to take a two week hiatus on this project to crank out some other software, but I intend to get back to it Monday, and I'm going to take a look at what @mlasak mentioned above. My fork of this was a successful build of Chromium from a couple weeks ago. Next week, I'll git pull HEAD and try the latest again. I have an Ubuntu VM setup now like @pwnall (thanks for the great wiki page, btw), and I'm going to be looking into the scrolling issue(s) again. |
|
@davisford This sounds good. I will try to pull your fork. If you manage to get the latest code built next week, please let me know, I'll do another pull. Hopefully we can make some progress on the scrolling issue :). |
|
Anyone else tried building Chromium? I've got a MBP with 8 cores, 8GB RAM, and an Ubuntu 12.04 VM in VMWare Fusion that I gave 4 cores and 4GB RAM. I built Chromium according to @pwnall wiki instructions a few weeks ago. I remember it taking pretty much all day to finish ~8 hours. I did a gclient sync yesterday...well, actually, I dropped the whole repo and re-pulled again b/c git seems to think I had modified the branch (which I hadn't), so I did a clean pull on the android branch from HEAD yesterday, and started the build yesterday AM. It is still linking more than 24 hours later. I'm just wondering if anyone else is building this behemoth? I think I should go grab an EC2 large instance to get this done. EDIT my mistake, I dropped the VM down to 1 core, 1GB RAM the other day, and forgot :) |
|
@davisford As build machine i used a virtualised Ubuntu 12.04 LTS 64bit with 30GB disk and 6GB RAM and 8GB swap partition on a MBP as host with 8GB and SSD. Starting from the tarball and after having synced the actual ninja build with content_shell_apk as target takes about 4h. On a dedicated machine with linux and comparable power it reduces to approx 1h. The incremental builds take only minutes depending on changes. No need to use EC2 ;) |
|
@mlasak yes, i forgot i changed the VM settings. changed them back and i finished the build. so, i copied the new src + binary artifacts over to my own chromeview fork, and i was able to build it and run the demo AlloChrome app with it. My fork now contains the latest chromium since yesterday but the scrolling issue is still broken in |
|
Is there any further updates on the scrolling behavior? |
|
On @mlasak's cue I looked into Chromium ContentShell. I've also been monitoring the chromium-dev list, and the Googlers on there indicate that ContentShell is a better starting point than AndroidWebView for building your own browser in Android. If you build Chromium, it does build ContentShell.apk that you can load on an Android device and it works great. It has an address bar and back and forward buttons, but these are Android UI widgets. You can build any browser you want. The scrolling works flawlessly with it. I've also loaded several websites to test it and it seems to work as you would expect Chromium to work. Unfortunately, there is no Android project per se that builds ContentShell.apk. It is constructed from several pieces of source littered all over the Chromium source. I have reverse engineered the build into a set of Android library projects and an Android app project that does build ContentShell and I have verified that it works, so now I've begun my own custom modifications to do with it what I'm looking to do. Edit: I'm going to clean it up and I will put something on Github that you can fork and use. |
|
that would be great! On Wed, Aug 28, 2013 at 8:15 PM, Davis Ford [email protected]:
|
|
Yes please ! That would be great ! 👍 |
|
@davisford that's good and anything you share on this is valuable. My suggestion is not to modify the contentshell codebase and chromium's build system at all, avoiding freeze to certain chromium state and avoiding generation of maintenance needs. Ideally we could run a shellscript that extracts everything necessary to create an Android Project that builds contentshell.apk -> Based on this working example anyone could integrate in own projects. Here's my script that still needs some tweaking so it does what we want: https://gist.github.com/mlasak/6374982 |
|
@mlasak that's exactly what I did. I did not modify the code, and I wrote shell scripts to to copy the necessary sources over if you want to update the browser. Well, there was one small modification I had to make, but it could also be augmented via shell scripts -- and I documented it well. |
|
Enjoy: https://github.com/davisford/android-chromium-view I may not have a lot of time to maintain this so if you want to help out (not just fork it), and have ideas to improve it, by all means. One thing I learned yesterday from the chromium-dev mailing list is that the content shell does not support file:///android- urls -- only AndroidWebView does. That is something I require, so I may be looking into how to write a workaround for that so that it does work in content shell. The next day or so, I'm also going to setup gdb debugging on the C++ sources. Java debug via ADT with my project works fine, but I want to step into the C++. If you also get this setup, I'd like to compare notes, and I'll add proper instruction in the README.md. Any questions / issues -- please file them over there, so other people will be able to find them -- as they relate to that project. Big thanks to @pwnall for doing the initial legwork on this. |
|
Nice work, really. I'm looking for file://android_assets/ file load too (like in cordova). I might work on this next week but if you find some workaround, I would be very interesting ! Should we create a thread on your repo's issues ? Thanks again ! |
|
@davisford Thanks. One of the reasons that pushed me to use AndroidWebView initially was that the content shell does not support file://... which is also something essential for our project as we are using content provider. I would be very interested to know how you get on with this as well. |
|
@gulian / @ziransun please see here -- doesn't seem like it would be all that difficult. The code is all there between the Chromium and Android repos, and they make it work with AndroidWebView. I see no reason why it couldn't be made to work with Content Shell. Please feel free to file an issue on this, and send pull requests too if you solve it :) BTW: it does support file:///absolute/path/urls -- just not the android-res urls |
ghost
mentioned this pull request
|
This might solve most issues here - http://developer.android.com/about/versions/kitkat.html#44-webview |
|
@ziransun while it is a great step in the right direction, and indeed it may solve a lot of issues for some people, there are reasons why one wants more control over the browser -- specifically a project i am doing has this need. this is why i split off a new repo here https://github.com/davisford/android-chromium -- the only thing it lacks at the moment is a build target for Android WebView -- which I intend to add, soon. there are build targets there for Chromium Content Shell and Test Shell -- which both work quite well. |
|
@davisford thanks. Apologize if I'm asking a silly question - I take your repo gives people an easy and fast way to build content/test shell if they don't intend to change any native codes. Otherwise, probably pull chromium source and build form there is the solution? |
|
@ziransun my repo provides two executable build targets:
The last target available in Chromium source tree for Android is Chromium AndroidWebView which is what they are using for the new KitKat announcement. It implements Android's WebView API -- while the others don't. If you absolutely need the WebView API (I don't) then you want to stick with KitKat only devices, I guess. I don't know if Android WebView will work on pre 4.4 or not, but I do know that ContentShell and TestShell both work on any 4.x release. I intend on adding Android WebView as a target to my repo when I get the time, so you can choose to build any of the three. If you need to edit the native code, then you'll have to build yourself. For most use cases, I think just editing the Java will get you what you need. Depends on your use case. I have not found a need to edit the native code myself. The Java APIs available cover most of the scenarios pretty well, once you learn your way around them. |
|
@ziransun one last point I want to add, the way the source is setup in a default Chromium checkout for Android is not standard -- i.e. how you'd expect for standard Android development. They use gyp and a whole host of other tools and their own generators to generate a lot of the code at build time. The value in breaking it out into something like a Gradle build (like I've done) is it makes it easy for Android devs to understand, build, fork, and edit. |
|
@davisford The last point you mentioned is definitely a plus - I can see the value of it :). Just trying to understand your repo, I haven't tried much with chromium's Content/Test Shell yet. You mentioned that your Test shell has some chrome features like sync, autofill, tabs. Does this mean that these features are supported in Chromium but just not built in Test Shell? or simply new features you introduced in? which chromium version you are working on? |
|
@ziransun all the code in that repo is Google's. The only thing I provided is a shell script to update it, and I organized it into easily consumable gradle projects. Test Shell has more Chrome features b/c they use it for testing, and they wanted to test those features. Check here for version info |
|
@davisford Thanks for the information. I'll try your repo - it's a good concept. Probably pop more question later in your repo space :). |
...webview