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 <jbo...@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:bows...@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 >> > <simon.macdon...@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 > >
