Bug 186444

Summary: [CoordGraphics] CompositingRunLoop assumes a WorkQueue has a RunLoop
Product: WebKit Reporter: Don Olmstead <don.olmstead>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: cgarcia, Hironori.Fujii, mcatanzaro, ysuzuki, zan
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=195208
Bug Depends on:    
Bug Blocks: 186364    

Don Olmstead
Reported 2018-06-08 13:54:55 PDT
CompositingRunLoop has a method runLoop() which gets the runLoop of a WorkQueue. This is GTK and generic run loop specific so WinCairo cannot currently use this.
Attachments
Yusuke Suzuki
Comment 1 2018-06-08 20:37:03 PDT
I don't think WorkQueue should expose RunLoop in its member function since it's implementation detail. If handling RunLoop is required, it means that WorkQueue abstraction is too high to use there. CompositingRunLoop should use RunLoop instead of WorkQueue I think.
Carlos Garcia Campos
Comment 2 2019-02-28 05:16:20 PST
We have two options here, either use our own thread with a run loop, or keep using a work queue, but making the timer creation platform specific (I guess in windows you could add a WorkQueue::timerQueue() similar to dispatchQueue() used by cocoa and runLoop() used by glib and generic) and create the timer with CreateTimerQueueTimer().
Carlos Garcia Campos
Comment 3 2019-03-01 06:58:46 PST
This will be fixed in bug #195208
Don Olmstead
Comment 4 2019-03-01 10:37:15 PST
*** This bug has been marked as a duplicate of bug 195208 ***
Note You need to log in before you can comment on or make changes to this bug.