Coordinate system in Windows GDI (1)
By Leezy_2000
2003-10-21 16:13
If you use GDI to output text, bitmap, or draw graphics such as straight, curve, then you will inevitably use the coordinate system. The screen resolution is 96dpi (Dot per inch), the resolution of the printer is usually 600dpi, and you are using
Moveto (HDC, 100, 100);
LINETO (HDC, 1300, 1300);
On both, the exact same two lines may be generated (hereinafter seeing WYSIWYG). In terms of implementation, the coordinate system plays a decisive role.
First, what is the GDI coordinate system?
First, from the perspective of mathematics, the GDI coordinate system is a two-dimensional coordinate system, and any location on the plane can be determined by two axes and origins.
From a perspective of use, the GDI coordinate system is a conversion rule that converts the logical data you make into the data that can be used in the final device. For example, (100,100), through the actual transformation, on the 96DPI screen may be (9.6, 9.6), which may be (60, 60) on the printer of 600dpi. (Note 1)
The GDI coordinate system consists of four-layer coordinate space (note), according to the high and low, respectively:
World-Space: Support Affine transformation, applied to the page coordinate spaces described below, only support in the NT class operating system.
Page Coordinate Space: Supports a large number of predefined mapping patterns, which is inevitably used coordinate space. The setting of origin and corresponding zoom ratio is suitable for setting in the page coordinate space.
The world coordinate space and page coordinate space are collectively referred to as logical coordinate space, which is the coordinate space that GDI users can use directly. That is to say, when the GDI output is performed, the location, size and other information such as the location, can only be data relative to the logical coordinate space.
Device-Space: The device space associated with the device context. A small piece or whole physical device can be represented by a physical device. Since the various GDI outputs are the device-oriented context, the relevant data in the logical coordinate space must naturally be converted into data in the device coordinate space.
Physical-Device Space: Part or all of the physical surface of the graphics device. That is, the coordinate space used by the graphics driver. Any GDI output ultimately wants to form a related driver on the display or printer, and the conversion of the device coordinate space to the physical device coordinate space is an inevitable. This process is completely completed by the system. So the origin and size information of the DC is read-only. (Confdition, which will be used as convenient below, using DC to represent the apparatus context)
Second, the output position is there?
The determination of the final output position can be seen by the above description, at least 2 transformations (if you enable the world coordinate space is 3 times), there is no way to directly determine any logical point will eventually correspond to the physical location? There is no existing, we come from self-realization, in fact, it is not complicated. First, the logical coordinates are converted into device coordinates. This process should be made in accordance with the Affine matrix and the current mapping mode, but we don't make this kind of operation now, but use
Bool Lptodp
HDC HDC, // Handle to Device Context
LPPOINT LPPOINTS, // Array Of Points
Int ncount // count of points in array
);
This function is responsible for converting logical coordinates in LPPoint to device coordinates associated with HDC. (Let's get this function later later).
Because the unit of equipment coordinates and physical device coordinates are consistent, they are physical device points. Therefore, the conversion from the equipment coordinates to physical equipment coordinates is not so troublesome, as long as the origin of the DC is, it is possible (note that the origin here refers to the location of the origin of the device coordinate space in the physical device coordinate space). The nature of this task is to read the DC structure of the OS, we use Bool getDcorgex (
HDC HDC, // Handle to A DC
LPPOINT LPPOINT / / TRANSLATION ORIGIN
);
To complete this task.
In this case, for any logical point LogicalPoint, the DC origin is DCORGPOINT:
PhysicalDevicePoint is the location of LogicalPoint in the physical device coordinate space. It will be described herein that the location of PhysicalDevicePoint is not necessarily the location of the physical surface because the physical device coordinate space does not necessarily cover the entire physical surface of the graphics device. For example, when printing, add a four-week non-printing area is its actual location. At the same time, the device is also considered to consider whether the physical device itself is scaled. If not (that is, the buttons without the display below) then you will find that the size we calculate is in line with the corresponding point on the screen. Very good.
Void getPhysicalPosition (HDC HDC, LPPOINT LPPOINT, INT NCOUNT) is used to complete the above functions. Source code 1 is referred to.
