GetDeviceCaps() with ASPECTX and ASPECTY

Rockoon · December 08, 2007, 04:18:55 AM

Does anyone know what units these values are in?

On my system, giving GetDeviceCaps a Device Context of my primary display (1280x1024 native) I get:

HORZSIZE = 337mm
VERTSIZE = 270mm
HORZRES = 1280px
VERTRES = 1024px

The size values are for sure in millimeters and are more or less correct (perhaps a few millimeters off...)

I also get:

ASPECTX = 36
ASPECTY = 36

I just can't seem to figure out what these units are in and my google karma is apparently lacking.

I dont mind relying on ASPECTX and ASPECTY but I would feel a lot more comfortable if I knew what units they were in.

The physical size of the pixels as I calculate them are:

337 / 1280 = 0.26328125mm
270 / 1024 = 0.26367188mm

and their reciprocals:

1280 / 337 = 3.79821958
1024 / 270 = 3.7925925

..any ideas?

MichaelW · December 08, 2007, 05:29:58 AM

I get 36 for both for my CRT at 1024x768Â (4:3) and 1280x1024 (5:4). From the little information returned by my searches, I suspect the value is the pixel aspect ratio (never mind how little sense that might make, given the way pixels are created on a color display), perhaps as a dimensionless number. Assuming you are using a flat panel display, what do you get at a non-native resolution?

Rockoon · December 08, 2007, 06:40:11 AM

Quote from: MichaelW on December 08, 2007, 05:29:58 AM
I get 36 for both for my CRT at 1024x768Â (4:3) and 1280x1024 (5:4). From the little information returned by my searches, I suspect the value is the pixel aspect ratio (never mind how little sense that might make, given the way pixels are created on a color display), perhaps as a dimensionless number. Assuming you are using a flat panel display, what do you get at a non-native resolution?

I was acting under the presumption that the ratio of these values was indeed the pixel aspect ratio..

..but by your suggestion, I tried a different graphics mode (1024x768) and again the same 36/36 falls out.

Interrestingly, in 1024x768 the HORZSIZE and VERTSIZE caps return different, incorrect, results. This is all contrary to my expectations. I expected HORZSIZE and VERTSIZE to remain constant over multiple video modes, reflecting the actual physical measurements of the display. They seem to only be accurate for my native LCD video mode and now I'm wondering if that was just by chance (seems unlikely since 5:4 displays like mine arent as common as the 4:3 displays)

sigh... I really wanted to be able to detect when pixels were square and now I'm wondering if thats even possible

MichaelW · December 08, 2007, 10:07:30 AM

I was hoping this would show something useful, but on my Sony CRT the aperture grille effects make it impossible to gauge (under 10x magnification) the aspect ratio of the pixels. Perhaps it will work better on other displays, or with some other pixel pattern.

Code Select


; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
include \masm32\include\masm32rt.inc
; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
drawline MACRO hdc,x1,y1,x2,y2
Â  invoke CreatePen, PS_SOLID, 0, 0
Â  invoke SelectObject, hdc, eax
Â  push eax
Â  invoke MoveToEx, hdc, x1, y1, NULL
Â  invoke LineTo, hdc, x2, y2
Â  pop eax
Â  invoke SelectObject, hdc, eax
Â  invoke DeleteObject, eax
ENDM
; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
.data
Â  Â  hWndÂ  ddÂ  Â  Â  Â  Â  0
Â  Â  hInst ddÂ  Â  Â  Â  Â  0
Â  Â  _xÂ  Â  ddÂ  Â  Â  Â  Â  0
Â  Â  _yÂ  Â  ddÂ  Â  Â  Â  Â  0
Â  Â  wcxÂ  Â WNDCLASSEXÂ  <>
Â  Â  wMsgÂ  MSGÂ  Â  Â  Â  Â <>
Â  Â  szDisplayNameÂ  Â  Â db "Test",0
Â  Â  szClassNameÂ  Â  Â  Â db "test_class",0
.code
; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
WindowProc proc uses ebx hwnd:DWORD, uMsg:DWORD,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â wParam:DWORD, lParam:DWORD
Â  Â  LOCAL ps :PAINTSTRUCT
Â  Â  SWITCH uMsg
Â  Â  Â  CASE WM_PAINT
Â  Â  Â  Â  invoke BeginPaint, hwnd, ADDR ps
Â  Â  Â  Â  xor ebx, ebx
Â  Â  Â  Â  .WHILE ebx < ps.rcPaint.bottom
Â  Â  Â  Â  Â  drawline ps.hdc, 0, ebx, ps.rcPaint.right, ebx
Â  Â  Â  Â  Â  add ebx, 3
Â  Â  Â  Â  .ENDW
Â  Â  Â  Â  xor ebx, ebx
Â  Â  Â  Â  .WHILE ebx < ps.rcPaint.right
Â  Â  Â  Â  Â  drawline ps.hdc, ebx, 0, ebx, ps.rcPaint.bottom
Â  Â  Â  Â  Â  add ebx, 3
Â  Â  Â  Â  .ENDW
Â  Â  Â  Â  invoke EndPaint, hwnd, ADDR ps
Â  Â  Â  CASE WM_CLOSE
Â  Â  Â  Â  invoke DestroyWindow, hwnd
Â  Â  Â  CASE WM_DESTROY
Â  Â  Â  Â  invoke PostQuitMessage, NULL
Â  Â  Â  DEFAULT
Â  Â  Â  Â  invoke DefWindowProc, hwnd, uMsg, wParam, lParam
Â  Â  Â  Â  ret
Â  Â  ENDSW
Â  Â  return 0
WindowProc endp
; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
start:
; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
Â  Â  invoke GetModuleHandle, NULL
Â  Â  mov hInst, eax
Â  Â  mov wcx.cbSize, SIZEOF WNDCLASSEX
Â  Â  mov wcx.style, CS_HREDRAW or CS_VREDRAW
Â  Â  mov wcx.lpfnWndProc, OFFSET WindowProc
Â  Â  mov wcx.cbClsExtra, NULL
Â  Â  mov wcx.cbWndExtra, NULL
Â  Â  push hInst
Â  Â  pop wcx.hInstance
Â  Â  invoke LoadIcon, NULL, IDI_APPLICATION
Â  Â  mov wcx.hIcon, eax
Â  Â  invoke LoadCursor, NULL, IDC_ARROW
Â  Â  mov wcx.hCursor, eax
Â  Â  mov wcx.hbrBackground, COLOR_HIGHLIGHTTEXT+1
Â  Â  mov wcx.lpszMenuName, NULL
Â  Â  mov wcx.lpszClassName, OFFSET szClassName
Â  Â  mov wcx.hIconSm, 0
Â  Â  invoke RegisterClassEx, ADDR wcx
Â  Â  W = 400
Â  Â  H = 300
Â  Â  invoke GetSystemMetrics, SM_CXSCREEN
Â  Â  shr eax, 1
Â  Â  sub eax, W / 2
Â  Â  mov _x, eax
Â  Â  invoke GetSystemMetrics, SM_CYSCREEN
Â  Â  shr eax, 1
Â  Â  sub eax, H / 2
Â  Â  mov _y, eax
Â  Â  invoke CreateWindowEx, NULL,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â ADDR szClassName,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â ADDR szDisplayName,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â WS_OVERLAPPED or WS_SYSMENU,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â _x, _y, W, H,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â NULL, NULL,
Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â hInst, NULL
Â  Â  mov hWnd, eax
Â  Â  invoke ShowWindow, hWnd, SW_SHOWNORMAL
Â  Â  invoke UpdateWindow, hWnd
Â  msgloop:
Â  Â  invoke GetMessage, ADDR wMsg, NULL, 0, 0
Â  Â  .IF eax != 0
Â  Â  Â  invoke TranslateMessage, ADDR wMsg
Â  Â  Â  invoke DispatchMessage, ADDR wMsg
Â  Â  Â  jmp msgloop
Â  Â  .ENDIF
Â  Â  exit
; Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«Â«
end start

Tedd · December 08, 2007, 06:00:02 PM

ASCPECTX and ASPECTY are the relative dimensions of a device pixel -- relative to what?!
Relative to the logical screen size, which is related to the DPI setting of the device (see LOGPIXELSX and LOGPIXELSY) to ensure fonts are sized sensibly on different sized devices/screens.
And as it's effectively a multiplier, there are no units.

Anyway, if ASPECTX==ASPECTY, the pixels are square.

Rockoon · December 08, 2007, 06:31:29 PM

Quote from: Tedd on December 08, 2007, 06:00:02 PM

Anyway, if ASPECTX==ASPECTY, the pixels are square.

Already shown not to be true.

To re-iterate,

in my LCD's native resolution in a 5:4 mode (1280x1024), ASPECTX=ASPECTY
on the same LCD, when its in a 4:3 mode (1024x768), ASPECTX=ASPECTY

..these both cannot be true if ASPECTX and ASPECTY have any meaning in regards to pixel width and height. I know that the first mode is the one with a true 1:1 pixel (physically measured the display with a ruler)

Here is the output of a prototype app I cooked up:

When in 1280x1024:

*SIZE = 337 270
*RES = 1280 1024
ASPECT* = 36 36

When in 1024x768:

*SIZE = 340 255
*RES = 1024 768
ASPECT* = 36 36

As you can see, instead of changing the ASPECT* values when the mode changes, it instead changed the HORZSIZE and VERTSIZE values and simply pretends that the pixels are square (which they are now not square.) Restated: the OS always assumes that display pixels are square.

It is unreasonable to expect end users to know what modes have square pixels and what modes do not, and it now seems unlikely that my app can even recommend a video mode or do any compensation since it doesnt seem possible to detect which ones have square pixels and which ones do not.

sigh..

jj2007 · December 08, 2007, 09:33:10 PM

Found this below at http://webster.cs.ucr.edu/Page_win32/WindowsAsmPgm/html/Ch07.html

Code Select


w.ASPECTX, w.ASPECTY and w.ASPECTXY will be very important to you.
These values specify the relative width, height, and diagonal length of pixels on the
screen. What this means is that if you draw a line segment that is n pixels long along the
X-axis, you would need to draw a line segment with (n*w.ASPECTY)/w.ASPECTX pixels
along the Y-axis to obtain a line that is physically the same size.
You would use these calculations to ensure that the shapes you draw on the screen
don't come out looking elongated or squashed. For example, when drawing a square on the
display, you would not draw an object with n pixels on each edge of the rectangle; doing so
would likely produce a rectangle whose sides have a different length than the top and
bottom line segments (that is, you'd have a proper rectangle rather than a square).
However, if you use the ratio w.ASPECTX:w.ASPECTY when drawing the sides of the
rectangle then the image you create will physically look like a square on the display
device. Generally, you'll only adjust one of the two coordinates via this ratio

In a nutshell: It's the width and height of a diagonal line. Probably relevant for those fancy little widescreen displays.

MichaelW · December 08, 2007, 10:47:19 PM

The Microsoft example here uses LOGPIXELSX and LOGPIXELSY, along with StretchDIBits to compensate for the difference in aspect ratios between the display and a printer.

Rockoon,

For a CRT even under the best conditions, where the displayed pixel pitch matched the dot pitch, with each dot composed of 0 to 3 (active) components I canâ€™t see how the aspect ratio of a pixel could have much meaning, or any readily predictable effect on image quality.

The only device on my system that allows me to specify a DPI where the x and y values differ is the NT Fax Driver. For the Normal (200x200 dpi) image quality setting:

ASPECTX 200
ASPECTY 200
LOGPIXELSX 200
LOGPIXELSY 200

For the Draft (200x100 dpi) image quality setting:

ASPECTX 100
ASPECTY 200
LOGPIXELSX 200
LOGPIXELSY 100

So ASPECTX and ASPECTY do seem to be connected to the DPI settings.

Rockoon · December 08, 2007, 11:07:35 PM

Quote from: jj2007 on December 08, 2007, 09:33:10 PM
In a nutshell: It's the width and height of a diagonal line. Probably relevant for those fancy little widescreen displays.

That is yet another incorrect resource :(

I am not the only person who has tried to tackle this issue it seems:

https://mollyrocket.com/forums/viewtopic.php?p=1940

He/She mentions LOGXPIXELSX and LOGPIXELSY, and when I prototype:

*SIZE = 337 270
*RES = 1280 1024
ASPECT* = 36 36
LOGPIXELS* = 96 96

*SIZE = 340 255
*RES = 1024 768
ASPECT* = 36 36
LOGPIXELS* = 96 96

Same problem. Both cannot be true.

Rockoon · December 08, 2007, 11:32:44 PM

Quote from: MichaelW on December 08, 2007, 10:47:19 PM
For a CRT even under the best conditions, where the displayed pixel pitch matched the dot pitch, with each dot composed of 0 to 3 (active) components I canâ€™t see how the aspect ratio of a pixel could have much meaning, or any readily predictable effect on image quality.

It matters not in "quality", but in geometric accuracy.

How do I draw a square?
How do I draw a circle?

If the "square" I draw appears as a rectangle, and the "circle" I draw appears as an oval, then surely you see the problem, right?

Consider an educational software game targeting 5 year old children, intended to be marketed to schools. This game is a geometry game intended to teach the children the difference between a rectangle and a square, and the diference between circles and ovals. It becomes of primary importance that squares really are square, and circles really are circles.

While for the resolutions 1280x1024 vs 1024x768 the difference is only about 7%, I have many display resolutions to choose from, yet only one of them actualy has a 5:4 size where pixels are square. Every other resolution choice offers a different pixel aspect ratio, some of them are very far from 1:1 (I can set a video mode intended for 16:10 wide screen monitors)

u · December 09, 2007, 12:13:21 AM

On a side note, the only place where I know pixels are non-rectangular is a PAL TV-out. And I haven't seen any monitor do aspect-correction, however simple that is (with the RAM and DSP they obviously already have to do stretching on LCD, and the circuitry they have on CRT). For the same reason I bet the monitor outputs predefined constants as its pixel-aspect ratio.
Just for an experiment, could someone with WinXP (not Win2k or earlier) see what the pixel-aspect ratio of the tv-out of the videocard is?

For the important task of that children's game, CRT monitors are always 4:3 (and no sane person would use non-4:3 screen-size, it's impossible to read text otherwise). LCD monitors will either be set at their native resolution or make text unreadable, too. Guess what- the customers solved their problem themselves :toothy. (this also shows the reasoning behind that constant 36:36 ratio).

It's silently become a standard to have square pixels, with LCDs having become predominant :).

jj2007 · December 09, 2007, 12:40:25 AM

Quote from: Ultrano on December 09, 2007, 12:13:21 AM
CRT monitors are always 4:3 (and no sane person would use non-4:3 screen-size, it's impossible to read text otherwise)

Sane or not sane, 16:9 is becoming the standard for home tv, and for ultraportable laptops.
Since Rockoon has no confidence in non-MS sources, here a quote from the Microsoft Windows Device Driver Kit (DDK) for Windows versions:

Code Select


Windows uses the AspectX, AspectY, and AspectXY constants returned by
GetDeviceCaps() to draw dotted and dashed lines that appear the same
regardless of the line's orientation. The AspectX and AspectY values are
dimensionless numbers that form the legs of a right triangle on the device;
the AspectXY value is the length of the hypotenuse. The ratio of AspectY to
AspectX is the aspect ratio of the device. The Windows graphics device
interface (GDI) uses this information to draw round circles, for example.
 
The AspectX, AspectY, and AspectXY values should be small (less than
100 each, for example). The size of these values impacts the length of
a patterned brush provided by GDI.
 
The LogPixelsX and LogPixelsY values describe the actual physical
resolution of the device.

ASPECTX & Y were not always 36:36 - see CGA:
GetDeviceCaps        CGA   EGA   VGA   8514/A
ASPECTX (horizontal)     5    38    36     10
ASPECTY (vertical)     12    48    36     10

Rockoon · December 09, 2007, 01:50:51 AM

Quote from: Ultrano on December 09, 2007, 12:13:21 AM
For the important task of that children's game, CRT monitors are always 4:3 (and no sane person would use non-4:3 screen-size, it's impossible to read text otherwise).

When I was running a CRT, I used the highest resolution that the monitor could sync to (1280x960), and that most definately did have square pixels.

My father OTOH, who now has that same CRT, runs at 1024x768 because 1280x960 makes text too small for him. Now you might argue that he could have altered the DPI settings in windows to produce the same effect.. but you would be wrong.. people who change the DPI setting in windows from 96 to anything else ("large fonts") eventualy regret it when poory written applications become unusable, and web pages unreadable.

For instance, http://blogs.msdn.com/oldnewthing/archive/2004/07/14/182971.aspx

Quote from: Ultrano on December 09, 2007, 12:13:21 AM
LCD monitors will either be set at their native resolution or make text unreadable, too.

..or will be set to the lowest resolution possible (likely to be 640x480) so the whole class can see whats on the screen.

We arent talking about programmers here. We are talking about people.

..and while it might seem fine to dismiss the people using other resolutions as being "insane" in passing conversation, it is not fine to do so from a software development standpoint. They might use "insane" resolutions.. they may type in "insane" filenames.. hell they might even have their desktop set to a 16-color (4-bit) graphics mode.. quality software addresses the idiot at the keyboard issue wherever possible.

Rockoon · December 09, 2007, 02:05:35 AM

Quote from: jj2007 on December 09, 2007, 12:40:25 AM
Since Rockoon has no confidence in non-MS sources, here a quote from the Microsoft Windows Device Driver Kit (DDK) for Windows versions:

I dont have confidence in any resources that disagrees with emperical evidence. I havent seen a single one that agrees with the evidence, including the one you just quoted. The non-MS resources seem to be simply regurgitating the MS resources, which are emperically incorrect.

Quote
ASPECTX & Y were not always 36:36 - see CGA:
GetDeviceCaps      Â Â CGA   EGA   VGA   8514/A
ASPECTX (horizontal)   Â 5    38    36   Â 10
ASPECTY (vertical)   Â Â 12    48    36   Â 10

See? They are constants! How can they be constants if they are supposed to represent pixel aspect ratios?

CGA for instance could do (among other lower resolutions) 320x200 (2-bit color) or 640x200 (1-bit color).

A 1" square in the later resolution would would be 2"x1" in the former...

u · December 09, 2007, 04:57:43 PM

Quote from: Rockoon on December 09, 2007, 01:50:51 AM
When I was running a CRT, I used the highest resolution that the monitor could sync to (1280x960), and that most definately did have square pixels.
My father OTOH, who now has that same CRT, runs at 1024x768 because 1280x960 makes text too small for him.

Both resolutions you mentioned are 4:3. No wonder "definitely square pixels".
I still stand firm behind the idea that GPU/display manufacturers and Microsoft have come to the conclusion, that almost all (if not absolutely all) users keep their AR correct. I see no other reason why my previous designers'-class CRT and my current 16:10 HDCP-enabled dual-input LCD monitor stretch any input to fit the whole screen, (and all LCDs disallow manual vertical stretching). Or it's all a bug in Windows, that has become a standard.

Now, let's stop pondering about how we would perform AR corrections, and see how professional software, whose primary selling point and concern is keeping AR and physical dimensions intact, does the job under Windows. Namely, launch Acrobat Reader with a document, where a square is shown. Switch to a screen-size with bad AR, and you get a nice rectangle. Ok, ok Acrobat is for printing correctly, but what about creating the documents? I bet the editor is also plagued by this "problem".

DPI and text-sizes aren't part of the topic, how about keeping the topic about ASPECTX and ASPECTY :) ?

P.S.

QuoteSane or not sane, 16:9 is becoming the standard for home tv, and for ultraportable laptops.

Read the context I wrote that in. It's about CRT monitors. Don't forget 16:10 is becoming the standard for home PCs.

News:

GetDeviceCaps() with ASPECTX and ASPECTY