win32: Whitespace cleanup

This commit is contained in:
Bryce Harrington 2018-02-06 15:08:17 -08:00
parent 4d07b57c16
commit dbe3d9ea51
2 changed files with 35 additions and 35 deletions

View file

@ -214,10 +214,10 @@ _create_dc_and_bitmap (cairo_win32_display_surface_t *surface,
goto FAIL;
surface->bitmap = CreateDIBSection (surface->win32.dc,
bitmap_info,
DIB_RGB_COLORS,
&bits,
NULL, 0);
bitmap_info,
DIB_RGB_COLORS,
&bits,
NULL, 0);
if (!surface->bitmap)
goto FAIL;
@ -289,8 +289,8 @@ _create_dc_and_bitmap (cairo_win32_display_surface_t *surface,
static cairo_surface_t *
_cairo_win32_display_surface_create_for_dc (HDC original_dc,
cairo_format_t format,
int width,
int height)
int width,
int height)
{
cairo_status_t status;
cairo_device_t *device;
@ -325,7 +325,7 @@ _cairo_win32_display_surface_create_for_dc (HDC original_dc,
surface->win32.extents.y = 0;
surface->win32.extents.width = width;
surface->win32.extents.height = height;
surface->win32.x_ofs = 0;
surface->win32.x_ofs = 0;
surface->win32.y_ofs = 0;
surface->initial_clip_rgn = NULL;
@ -634,26 +634,26 @@ _cairo_win32_save_initial_clip (HDC hdc, cairo_win32_display_surface_t *surface)
surface->win32.extents.height = rect.bottom - rect.top;
/* On multi-monitor setup, under Windows, the primary monitor always
* have origin (0,0). Any monitors that extends to the left or above
* have origin (0,0). Any monitors that extends to the left or above
* will have coordinates in the negative range. Take this into
* account, by forcing our Win32 surface to start at extent (0,0) and
* using a device offset. Cairo does not handle extents with negative
* account, by forcing our Win32 surface to start at extent (0,0) and
* using a device offset. Cairo does not handle extents with negative
* offsets.
*/
*/
surface->win32.x_ofs = 0;
surface->win32.y_ofs = 0;
if ((surface->win32.extents.x < 0) ||
(surface->win32.extents.y < 0)) {
/* Negative offsets occurs for (and ONLY for) the desktop DC (virtual
* desktop), when a monitor extend to the left or above the primary
* monitor.
*
* More info @ https://www.microsoft.com/msj/0697/monitor/monitor.aspx
*
* Note that any other DC, including memory DC created with
* desktop), when a monitor extend to the left or above the primary
* monitor.
*
* More info @ https://www.microsoft.com/msj/0697/monitor/monitor.aspx
*
* Note that any other DC, including memory DC created with
* CreateCompatibleDC(<virtual desktop DC>) will have extents in the
* positive range. This will be taken into account later when we perform
* raster operations between the DC (may have to perform offset
* positive range. This will be taken into account later when we perform
* raster operations between the DC (may have to perform offset
* translation).
*/
surface->win32.x_ofs = surface->win32.extents.x;

View file

@ -102,20 +102,20 @@ typedef struct _cairo_win32_surface {
cairo_rectangle_int_t extents;
/* Offset added to extents, used when the extents start with a negative
* offset, which occur on Windows for, and only for, desktop DC. This
* occurs when you have multiple monitors, and at least one monitor
* extends to the left, or above, the primaty monitor. The primary
* monitor on Windows always start with offset (0,0), and any other points
* to the left, or above, have negative offset. So the 'desktop DC' is
* in fact a 'virtual desktop' which can start with extents in the negative
* range.
*
* Why use new variables, and not the device transform? Simply because since
* the device transform functions are exposed, a lot of 3rd party libraries
* simply overwrite those, disregarding the prior content, instead of actually
* adding the offset. GTK for example simply reset the device transform of the
* desktop cairo surface to zero. So make some private member variables for
* this, which will not be fiddled with externally.
* offset, which occur on Windows for, and only for, desktop DC. This
* occurs when you have multiple monitors, and at least one monitor
* extends to the left, or above, the primaty monitor. The primary
* monitor on Windows always start with offset (0,0), and any other points
* to the left, or above, have negative offset. So the 'desktop DC' is
* in fact a 'virtual desktop' which can start with extents in the negative
* range.
*
* Why use new variables, and not the device transform? Simply because since
* the device transform functions are exposed, a lot of 3rd party libraries
* simply overwrite those, disregarding the prior content, instead of actually
* adding the offset. GTK for example simply reset the device transform of the
* desktop cairo surface to zero. So make some private member variables for
* this, which will not be fiddled with externally.
*/
int x_ofs, y_ofs;
} cairo_win32_surface_t;
@ -200,7 +200,7 @@ cairo_private void
_cairo_win32_display_surface_discard_fallback (cairo_win32_display_surface_t *surface);
cairo_bool_t
_cairo_win32_surface_get_extents (void *abstract_surface,
_cairo_win32_surface_get_extents (void *abstract_surface,
cairo_rectangle_int_t *rectangle);
uint32_t
@ -216,7 +216,7 @@ _cairo_win32_surface_emit_glyphs (cairo_win32_surface_t *dst,
static inline void
_cairo_matrix_to_win32_xform (const cairo_matrix_t *m,
XFORM *xform)
XFORM *xform)
{
xform->eM11 = (FLOAT) m->xx;
xform->eM21 = (FLOAT) m->xy;