1383083 - Remove use of win32k gdi calls when printing

Status: RESOLVED FIXED

(Core :: Graphics, enhancement, P3)

Description

[Alex Gaynor [:Alex_Gaynor]]

Currently when a print is triggered (I tested this with a print-to-pdf), we perform the drawing in the content process -- this results in use of the GDI win32k APIs. I believe for normal web page rendering we use skia for drawing, and then use cairo for compositing in the chrome process. Here's an example stack:

    win32u!NtGdiCreateCompatibleDC
    gdi32full!CreateCompatibleDC+0x13
    dwrite!MemoryDC::MemoryDC+0x2f
    dwrite!DWriteBitmapRenderTarget::DWriteBitmapRenderTarget+0x43
    dwrite!DWriteGdiInterop::CreateBitmapRenderTarget+0x53
    xul!_dwrite_draw_glyphs_to_gdi_surface_gdi+0xb9
    xul!_cairo_dwrite_show_glyphs_on_surface+0x47f
    xul!_cairo_win32_surface_show_glyphs_internal+0x74
    xul!_cairo_win32_surface_show_glyphs+0x43
    xul!_cairo_surface_show_text_glyphs+0x201
    xul!_cairo_gstate_show_text_glyphs+0x302
    xul!_moz_cairo_show_glyphs+0x4d
    xul!mozilla::gfx::DrawTargetCairo::FillGlyphs+0x25f
    xul!mozilla::gfx::DrawTargetWrapAndRecord::FillGlyphs+0x473
    xul!GlyphBufferAzure::Flush+0x1f0
    xul!GlyphBufferAzure::{dtor}+0xb
    xul!gfxFont::DrawGlyphs+0x1cf
    xul!gfxFont::Draw+0x741
    xul!gfxTextRun::DrawGlyphs+0xb5
    xul!gfxTextRun::Draw+0x3f4
    xul!nsFontMetrics::DrawString+0x11f
    xul!nsLayoutUtils::DrawUniDirString+0x71
    xul!nsLayoutUtils::DrawString+0x18b
    xul!nsPageFrame::DrawHeaderFooter+0x27e
    xul!nsPageFrame::DrawHeaderFooter+0xb9
    xul!nsPageFrame::PaintHeaderFooter+0x274
    xul!nsDisplayHeaderFooter::Paint+0x22
    xul!mozilla::FrameLayerBuilder::PaintItems+0x46f
    xul!mozilla::FrameLayerBuilder::DrawPaintedLayer+0x824
    xul!mozilla::layers::BasicPaintedLayer::PaintThebes+0x2e2
    xul!mozilla::layers::BasicLayerManager::PaintSelfOrChildren+0x65
    xul!mozilla::layers::BasicLayerManager::PaintLayer+0xa2f
    xul!mozilla::layers::BasicLayerManager::PaintSelfOrChildren+0x125
    xul!mozilla::layers::BasicLayerManager::PaintLayer+0xa2f
    xul!mozilla::layers::BasicLayerManager::EndTransactionInternal+0x3e5
    xul!nsDisplayList::PaintRoot+0x9e8
    xul!nsLayoutUtils::PaintFrame+0xc94
    xul!nsSimplePageSequenceFrame::PrintNextPage+0x2cb
    xul!nsPrintEngine::PrintPage+0x2ee

Comment 1

[Chris Martin [:cmartin]]

I did a bunch of testing on my machine with Win32k Lockdown enabled. I printed to PDF, I used a real printer, I tried printing pages with pictures, fancy fonts, etc.

There were no additional Win32k call stacks in any of these situations that were unique to printing (We still have a few Win32k calls in normal logs -- Those have bugs assigned already).

Although testing can't prove the absence of bugs, I think at this point it makes more sense for us to close this bug and rely on community testing and the filing of new bugs to drive this forward.