You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Simon MacDonald <si...@gmail.com> on 2012/11/22 21:55:48 UTC
Android WebView
Hey all,
Anything we can use from this SO answer to make the webview faster?
http://stackoverflow.com/questions/13500452/android-webview-renders-blank-white-view-doesnt-update-on-css-changes-or-html
Simon Mac Donald
http://hi.im/simonmacdonald
Re: Android WebView
Posted by Andrew Grieve <ag...@chromium.org>.
Yeah, a lot of those changes seem risky. The invalidate for sure, but also
making every div in your app hw-accelerated will work only for extremely
small DOMs, and in the average case cause more harm than good. That said,
carefully selecting which elements to apply that to goes a long way.
Upping the priority of the renderer thread seems like something we could
try out.
On Thu, Nov 22, 2012 at 5:54 PM, Joe Bowser <bo...@gmail.com> wrote:
> I don't think that's necessarily right. Calling invalidate forces the
> re-render of the canvas with whatever data is sent to it in mPicture
> as well as whatever the WebView overlays. The fact that you have to
> call invalidate() after the draw() just to get the up-to-date mPicture
> is a bug. It would be better to see if mPicture was updated after the
> draw and to only issue a redraw at that time, but even then there
> might be issues.
>
> I wonder how other browser implementations handle this.
>
> On Thu, Nov 22, 2012 at 2:30 PM, Jonathan Bond-Caron <jb...@openmv.com>
> wrote:
> > Ya calling invalidate() right after onDraw() is wrong.
> >
> > My experience is only with ICS on JB, but invalidate() will only affect
> > native/java (e.g. an android rectangle EditText on top of an HTML input).
> > It has no impact on the HTML/CSS webkit engine.
> >
> > It's actually the other way around, the webkit engine (c++) calls
> > viewInvalidate() in c++ when in the DOM cursor/scrolling etc.. events
> > happen, this calls invalidate() in java.
> > The purpose of invalidate() is to force the re-render of *java*
> components
> > painted on the canvas.
> >
> >> -----Original Message-----
> >> From: Joe Bowser [mailto:bowserj@gmail.com]
> >> Sent: November 22, 2012 4:51 PM
> >> To: dev
> >> Subject: Re: Android WebView
> >>
> >> OK, so what's the downside of constantly forcing the view to be redrawn
> >> over and over again? That's the thing that I would be most concerned
> >> about.
> >> >
> >> >
> >> > On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald
> >> > <si...@gmail.com>wrote:
> >> >
> >> >> Hey all,
> >> >>
> >> >> Anything we can use from this SO answer to make the webview faster?
> >> >>
> >> >>
> >> >> http://stackoverflow.com/questions/13500452/android-webview-renders-
> >> b
> >> >> lank-white-view-doesnt-update-on-css-changes-or-html
> >
> >
>
Re: Android WebView
Posted by Joe Bowser <bo...@gmail.com>.
I don't think that's necessarily right. Calling invalidate forces the
re-render of the canvas with whatever data is sent to it in mPicture
as well as whatever the WebView overlays. The fact that you have to
call invalidate() after the draw() just to get the up-to-date mPicture
is a bug. It would be better to see if mPicture was updated after the
draw and to only issue a redraw at that time, but even then there
might be issues.
I wonder how other browser implementations handle this.
On Thu, Nov 22, 2012 at 2:30 PM, Jonathan Bond-Caron <jb...@openmv.com> wrote:
> Ya calling invalidate() right after onDraw() is wrong.
>
> My experience is only with ICS on JB, but invalidate() will only affect
> native/java (e.g. an android rectangle EditText on top of an HTML input).
> It has no impact on the HTML/CSS webkit engine.
>
> It's actually the other way around, the webkit engine (c++) calls
> viewInvalidate() in c++ when in the DOM cursor/scrolling etc.. events
> happen, this calls invalidate() in java.
> The purpose of invalidate() is to force the re-render of *java* components
> painted on the canvas.
>
>> -----Original Message-----
>> From: Joe Bowser [mailto:bowserj@gmail.com]
>> Sent: November 22, 2012 4:51 PM
>> To: dev
>> Subject: Re: Android WebView
>>
>> OK, so what's the downside of constantly forcing the view to be redrawn
>> over and over again? That's the thing that I would be most concerned
>> about.
>> >
>> >
>> > On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald
>> > <si...@gmail.com>wrote:
>> >
>> >> Hey all,
>> >>
>> >> Anything we can use from this SO answer to make the webview faster?
>> >>
>> >>
>> >> http://stackoverflow.com/questions/13500452/android-webview-renders-
>> b
>> >> lank-white-view-doesnt-update-on-css-changes-or-html
>
>
RE: Android WebView
Posted by Jonathan Bond-Caron <jb...@openmv.com>.
Ya calling invalidate() right after onDraw() is wrong.
My experience is only with ICS on JB, but invalidate() will only affect
native/java (e.g. an android rectangle EditText on top of an HTML input).
It has no impact on the HTML/CSS webkit engine.
It's actually the other way around, the webkit engine (c++) calls
viewInvalidate() in c++ when in the DOM cursor/scrolling etc.. events
happen, this calls invalidate() in java.
The purpose of invalidate() is to force the re-render of *java* components
painted on the canvas.
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: November 22, 2012 4:51 PM
> To: dev
> Subject: Re: Android WebView
>
> OK, so what's the downside of constantly forcing the view to be redrawn
> over and over again? That's the thing that I would be most concerned
> about.
> >
> >
> > On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald
> > <si...@gmail.com>wrote:
> >
> >> Hey all,
> >>
> >> Anything we can use from this SO answer to make the webview faster?
> >>
> >>
> >> http://stackoverflow.com/questions/13500452/android-webview-renders-
> b
> >> lank-white-view-doesnt-update-on-css-changes-or-html
Re: Android WebView
Posted by Joe Bowser <bo...@gmail.com>.
OK, so what's the downside of constantly forcing the view to be
redrawn over and over again? That's the thing that I would be most
concerned about.
On Thu, Nov 22, 2012 at 1:37 PM, Braden Shepherdson <br...@chromium.org> wrote:
> The first paragraph of his answer is entirely in line with my claim that
> Android WebView is the new IE6. It's slow, buggy, doesn't follow the
> standards, and it will be years before we're rid of it.
>
> Interesting comments about the invalidation. I haven't seen most of the
> problems he's been having in a Phonegap app, but I have certainly seen them
> on the old Android Browser when I was working on mobile web G+.
>
> Braden
>
>
> On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald
> <si...@gmail.com>wrote:
>
>> Hey all,
>>
>> Anything we can use from this SO answer to make the webview faster?
>>
>>
>> http://stackoverflow.com/questions/13500452/android-webview-renders-blank-white-view-doesnt-update-on-css-changes-or-html
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
Re: Android WebView
Posted by Braden Shepherdson <br...@chromium.org>.
The first paragraph of his answer is entirely in line with my claim that
Android WebView is the new IE6. It's slow, buggy, doesn't follow the
standards, and it will be years before we're rid of it.
Interesting comments about the invalidation. I haven't seen most of the
problems he's been having in a Phonegap app, but I have certainly seen them
on the old Android Browser when I was working on mobile web G+.
Braden
On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald
<si...@gmail.com>wrote:
> Hey all,
>
> Anything we can use from this SO answer to make the webview faster?
>
>
> http://stackoverflow.com/questions/13500452/android-webview-renders-blank-white-view-doesnt-update-on-css-changes-or-html
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>