Do not use win32k renderer lockdown if DirectWrite is disabled.

Do not use Win32k renderer lockdown if DirectWrite is disabled.

OOP PDF is now enabled by default, so remove the check in ChromeBrowserMainPartsWin::PreCreateThreads

BUG=442157
TEST=launch with --enable-win32k-renderer-lockdown or --force-fieldtrials=Win32kLockdown/Enabled/ check chrome://histograms that Win32k lockdown is enabled.  Check OOP PDF still works both with and without --disable-direct-write switch.

Committed: https://crrev.com/6575fb417dde94ff8dc9e7aca1c02f7b0bf316a7
Cr-Commit-Position: refs/heads/master@{#313423}

[Will Harris, 2015-01-24 01:44:41]

wfh@chromium.org changed reviewers:
+ ananta@chromium.org, jam@chromium.org

[Will Harris, 2015-01-24 01:44:54]

wfh@chromium.org changed reviewers:
+ cpu@chromium.org

[Will Harris, 2015-01-24 07:03:09]

The CL looks slightly complex but the win32k status is accessed from both Chrome
(for OOP PDF) and Content (for everything else), so had to be somewhere in
content/public.

Unfortunately, a few targets (e.g. crash and print service, nacl64) link with
content_switches.cc so I can't call directly out of there to ui::gfx so had to
move the function out to a new file.  Suggestions welcome on where else I could
put this function, or a better name for the file!

cpu@ -> sandbox/win
jam@ -> content/
ananta@ -> comments appreciated!

[jam, 2015-01-26 16:02:49]

is this a reland of a previous cl? if so it would have been easier to upload to
same issue so we can compare changes from previous landing and see previous
comments.

the _impl suffix is used in files outside of content/public, i.e. in
content/browser etc.. why did you create a new file instead of keeping it in
content_switches and just linking that into more targets?

[Will Harris, 2015-01-26 17:23:40]

On 2015/01/26 16:02:49, jam wrote:
> is this a reland of a previous cl? if so it would have been easier to upload
to
> same issue so we can compare changes from previous landing and see previous
> comments.
> 

The other CL was never landed, and this was so different from the previous one
that I thought best to use another CL.  I'm happy to tag this onto the original
if you prefer - the other one was https://codereview.chromium.org/857123002/

> the _impl suffix is used in files outside of content/public, i.e. in
> content/browser etc.. why did you create a new file instead of keeping it in
> content_switches and just linking that into more targets?

switches::IsWin32kRendererLockdownEnabled calls gfx::win::ShouldUseDirectWrite
which in turn calls gfx::GetDPIScale which in turn calls into
gfx::Display::GetUnforcedDeviceScaleFactor which calls into gfx::GetDPI which
means splitting out and then pulling in code from direct_write.cc, dpi.cc and
display.cc (because these files call into Skia and other parts), then linking
them into the targets that link directly with content_switches.cc without
depending on the content_common target.  This is cloud_print_service_lib,
crash_service_win64 and nacl_win64.

I felt it was far less invasive to change all the code in gfx:: to export just
the minimum set to determine directwrite status, than just to place the
IsWin32kRendererLockdownEnabled call into a cc file that was only linked if the
target depended on content_common.

[jam, 2015-01-26 19:53:16]

does it make things easier if the IsWin32kRendererLockdownEnabled call in chrome
is removed? I just looked at it and it looks like it's not needed anymore, since
pdf is out of process by default now

[Will Harris, 2015-01-26 20:53:47]

On 2015/01/26 19:53:16, jam wrote:
> does it make things easier if the IsWin32kRendererLockdownEnabled call in
chrome
> is removed? I just looked at it and it looks like it's not needed anymore,
since
> pdf is out of process by default now

Yes that makes it far simpler - then I can just push the
IsWin32kRendererLockdownEnabled into content/common/content_switches_internal.cc

if OOP PDF is always enabled, I can upload a CL with that in it, and verify that
PDF still functions correctly.

[jam, 2015-01-26 22:02:33]

On 2015/01/26 20:53:47, Will Harris wrote:
> On 2015/01/26 19:53:16, jam wrote:
> > does it make things easier if the IsWin32kRendererLockdownEnabled call in
> chrome
> > is removed? I just looked at it and it looks like it's not needed anymore,
> since
> > pdf is out of process by default now
> 
> Yes that makes it far simpler - then I can just push the
> IsWin32kRendererLockdownEnabled into
content/common/content_switches_internal.cc
> 
> if OOP PDF is always enabled, I can upload a CL with that in it, and verify
that
> PDF still functions correctly.

yes see
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/chro...

[Will Harris, 2015-01-27 02:17:00]

Patchset #7 (id:120001) has been deleted

[Will Harris, 2015-01-27 04:12:17]

Moved the IsWin32kRendererLockdownEnabled to content/common.  PTAL.

https://codereview.chromium.org/872673002/diff/140001/content/browser/browser...
File content/browser/browser_main_loop.cc (right):

https://codereview.chromium.org/872673002/diff/140001/content/browser/browser...
content/browser/browser_main_loop.cc:1072: #endif
wasn't sure the best place to put this histogram.

[jam, 2015-01-27 23:58:04]

lgtm

[ananta, 2015-01-28 00:04:23]

lgtm

[cpu_(ooo_6.6-7.5), 2015-01-28 00:10:31]

lgtm

[Will Harris, 2015-01-28 00:13:26]

The CQ bit was checked by wfh@chromium.org

[commit-bot: I haz the power, 2015-01-28 00:14:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/872673002/140001

[commit-bot: I haz the power, 2015-01-28 04:05:47]

Committed patchset #7 (id:140001)

[commit-bot: I haz the power, 2015-01-28 04:06:34]

Patchset 7 (id:??) landed as
https://crrev.com/6575fb417dde94ff8dc9e7aca1c02f7b0bf316a7
Cr-Commit-Position: refs/heads/master@{#313423}