Bug 186444 - [CoordGraphics] CompositingRunLoop assumes a WorkQueue has a RunLoop
Summary: [CoordGraphics] CompositingRunLoop assumes a WorkQueue has a RunLoop
Status: RESOLVED DUPLICATE of bug 195208
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 186364
  Show dependency tree / graph
 
Reported: 2018-06-08 13:54 PDT by Don Olmstead
Modified: 2019-03-01 10:37 PST (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Don Olmstead 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.
Comment 1 Yusuke Suzuki 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.
Comment 2 Carlos Garcia Campos 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().
Comment 3 Carlos Garcia Campos 2019-03-01 06:58:46 PST 
This will be fixed in bug #195208
Comment 4 Don Olmstead 2019-03-01 10:37:15 PST 

*** This bug has been marked as a duplicate of bug 195208 ***