[cairo-bugs] [Bug 100793] New: Issue with multiple-monitor setup with the desktop DC.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=100793

            Bug ID: 100793
           Summary: Issue with multiple-monitor setup with the desktop DC.
           Product: cairo
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: win32 backend
          Assignee: cairo-bugs at cairographics.org
          Reporter: ehoffman at videotron.ca
        QA Contact: cairo-bugs at cairographics.org

Created attachment 131034
  --> https://bugs.freedesktop.org/attachment.cgi?id=131034&action=edit
Multi-monitor issue with negative extent patch

Hi

I was actually initially investigating an issue with Gimp, but the root of the
issue really is with cairo.

Under Win32, when you have multiple-monitor setup, Windows create a 'virtual
desktop', which is a rectangle surface that extend all monitors.

The primary monitor always start with the top-left corner at coordinate (0,0). 
If you have any other monitors which extends to the left, or above the primary
monitor, the virtual desktop top-left corner will actually have coordinates
which are negative.

This create an issue in cairo when you use the desktop DC, i.e. when you use a
DC from the function GetDC(NULL).  The same think occur with other third party
libraries like GTK, when you access the cairo surface from the root window.

In GIMP, I did apply a patch for the color picker, by using Windows native code
for the affected function, but past that, I have investigated cairo and did a
patch for this issue.

Basically, when the _cairo_win32_save_initial_clip() function is called with a
DC, it get and save the extent.  When (and only when) the provided DC is the
desktop DC, it is possible that the extent starts with a negative x,y.  In this
case, and since the desktop DC will not be clipped, we can check if the extents
x,y are negative.  In this case, make the extents start at (0,0), and record
the offset.

Then, when performing image map/unmap, the BitBlt function has to take this
offset into account.  For example, the fallback DC, even though it's created
with CreateCompatibleDC, will have it's extents x,y at (0,0).  For a one to one
copy between the original DC, and the fallback DC, the translation has to be
taken into account.

That is what this patch does.  So basically, under Win32, the desktop DC will
always start at (0,0).  This is in like with other libraries, like GTK, which
return screen coordinates starting at (0,0).

That is also probably the root cause of bug 96482 (Cairo 1.15.2: Crash in
cairo_fill if target surface is created with cairo_win32_surface_create), since
in that bug, when the author apply a positive viewport transform, the DC most
probably return a negative offset.

That may be the the root cause of bug 69617 too, although I'm not sure...
(GIMP's color picker of color dialog not work, returns black).

Regards,
Eric Hoffman

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo-bugs/attachments/20170426/896f394f/attachment.html>