Bug 141576 - MiniBrowser doesn't use accelerated drawing in WebKit2 windows if a WebKit1 window was opened first
Summary: MiniBrowser doesn't use accelerated drawing in WebKit2 windows if a WebKit1 w...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-13 14:18 PST by Tim Horton
Modified: 2016-03-23 14:06 PDT (History)
4 users (show)

See Also:

Attachments
Patch (1.61 KB, patch)
2016-03-23 12:07 PDT, Tim Horton 		simon.fraser: review+
Details | Formatted Diff | Diff
View All 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 Tim Horton 2015-02-13 14:18:59 PST 
WebKit1 registers a huge dictionary of NSUserDefaults, including WebKitAcceleratedDrawingEnabled=NO.

In WebKit2, the acceleratedDrawingEnabled pref defaults to true, but we first read debug prefs (one of which is WebKitAcceleratedDrawingEnabled) from NSUserDefaults.

So, if you have a process where WebKit1 and WebKit2 coexist, and WebKit1 is set up first, you'll end up with accelerated drawing off by default in subsequently created WebKit2 views despite the WebKit2 default intending to have that preference on.
Comment 1 Tim Horton 2016-03-23 00:09:24 PDT 
<rdar://problem/25304548>
Comment 2 Tim Horton 2016-03-23 12:07:45 PDT 
Created attachment 274767 [details]
Patch
Comment 3 Simon Fraser (smfr) 2016-03-23 12:09:38 PDT 
Comment on attachment 274767 [details]
Patch

Do we use these defaults in WTR?
Comment 4 Tim Horton 2016-03-23 12:15:43 PDT 
(In reply to comment #3)
> Comment on attachment 274767 [details]
> Patch
> 
> Do we use these defaults in WTR?

Doesn't appear so. WKTR uses the preferences API.
Comment 5 Tim Horton 2016-03-23 14:06:55 PDT 
http://trac.webkit.org/changeset/198593