[Webkit-unassigned] [Bug 34214] HostWindow repaint and friends need a refactor

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=34214





--- Comment #8 from Adam Treat <treat at kde.org>  2010-02-02 13:28:24 PST ---
(In reply to comment #7)
> (From update of attachment 47534 [details])
> I don't like some of the names chosen here.  I don't think they're very clear.
> 
> There are basically eight combinations for the repaint method.
> 
> The operations that are interesting in repaint are:
> (1) Adding a dirty region to the backing store (contentChanged = true).
> (2) Adding a dirty region to your native window (repaintContentOnly = false)
> (3) Painting immediately (immediate = true) (which either means updating the
> backing store synchronously or updating the native window synchronously)
> 
> Thus the following operations are possible (both synchronous and asynchronous):
> 
> (1) Add a dirty region to the backing store and invalidate it (contentChanged =
> true, repaintContentOnly = true)
> (2) Invalidate a portion of the window (contentChanged = false,
> repaintContentOnly = false)
> (3) Add a dirty region to the backing store and invalidate both the backing
> store and the window (contentChanged = true, repaintContentOnly = false)
> (4) Do nothing (contentChanged = false, repaintContentOnly = true).  Nonsense
> option.
> 
> So now we're down to six options. I think the way to break this up is to
> separate repainting of contents from just invalidating the window.
> 
> Here are my suggestions:
> 
> virtual void invalidateContents(const IntRect& updateRect, bool immediate =
> false);
>     This method covers (1) above, both the synchronous and asynchronous case.
> 
> virtual void invalidateWindow(const IntRect& updateRect, bool immediate =
> false);
>     This method covers (2) above, both the synchronous and asynchronous case.
> 
> virtual void invalidateContentsAndWindow(const IntRect& updateRect, bool
> immediate = false);
>     This method covers (3) above, both the synchronous and asynchronous case.

So these three methods + the two scrolling methods? hostWindow()->scroll and
hostWindow->repaintForSlowScroll ?

I think it is important to keep the scrolling methods separate as this provides
contextual information to the port about *why* the invalidation is taking
place.  Different ports have very different painting models and I know that it
is useful to have this contextual information in some cases.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.