[Webkit-unassigned] [Bug 37658] New: Apple's Windows port has different behavior from all other ports with handling HostWindow invalidate methods

[bugzilla-daemon at webkit.org]

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

           Summary: Apple's Windows port has different behavior from all
                    other ports with handling HostWindow invalidate
                    methods
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: treat at kde.org


When refactoring the HostWindow 'repaint' methods away from bool parameter soup
I noticed that the Windows port has different behavior than all other ports. 
Specifically, the Windows port is the only one that makes use of the
HostWindow::invalidateWindow method.  This method is called in
ScrollView::scrollContents before the other 'invalidate' methods.  I sat down
with Adam Roben to try and understand why this was necessary and couldn't quite
piece it together.

Another odd thing is that invalidateForSlowScroll is called asynchronously. 
But I think this is wrong.  Rather, it needs to be called synchronously so that
the blit that is done at the end of scrollContents will update the window with
this slow scroll.

Anyways, trying to draw in relevant people to figure out what bugs exist here
and what can be done to fix them and make this code more robust.

Adam

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