Why are RECTs endpoint-exclusive?

re: Why are RECTs endpoint-exclusive?

Alex Black — Wed, 18 Feb 2004 17:44:00 GMT

Hi Raymond, I ran into issues related to this just yesterday! (great BLOG btw).

1) What is the width of a RECT?
width = rect.right - rect.left +1?

2) Are RECTs ever interpreted differently? consider FillRect vs. InvalidateRect or GetClientRect

Basically, I have a VB picturebox, that is 640x480 pixels. I call GetClientRect and get (0,0,640,480), then I call MyGetRectWidth(rect) and get 639!

am I misunderstanding something here? :)

thx!

- Alex

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Wed, 18 Feb 2004 17:55:00 GMT

The width of a rectangle is "rect.right-rect.left" and you should assume that's how all Windows functions treat rectangles. Any exceptions are (or should be) explicitly called out in the function documentation. I don't know of any exceptions offhand.

re: Why are RECTs endpoint-exclusive?

Mark Smith — Wed, 18 Feb 2004 18:33:00 GMT

It's 20 years old, but the Quickdraw section of Inside Macintosh Volume I still has the clearest explanation of why coordinates-between-the-pixels is a Good Thing.

re: Why are RECTs endpoint-exclusive?

Dan Maas — Wed, 18 Feb 2004 18:48:00 GMT

I think the preferred convention is that the center of pixel N,M is at (N+0.5,M+0.5), and if you must use a box filter, then the footprint of the filter is N <= x < N+1 and M <= y < M+1.

The reason we do this is the same reason arrays start at zero rather than one in C. It seems awkward at first, but it makes the math much cleaner.

re: Why are RECTs endpoint-exclusive?

Mike Dimmick — Wed, 18 Feb 2004 20:15:00 GMT

You might want to tell the Windows CE guys: FillRect draws one pixel more to the right and bottom on CE than it does on the desktop.

Of course, there's the backwards-compatibility issue: if it gets changed now, it breaks every program already written for CE. Not nearly as many as on the desktop, true, but a significant enough number.

I wonder if this wart made it into .NET CF?

re: Why are RECTs endpoint-exclusive?

CW user — Wed, 18 Feb 2004 22:05:00 GMT

And then there are MetaFiles. Raymond can you tell us a story
what's happening with rectangles when we use them with
(Enhanced)MetaFiles?

Please! Please!

re: Why are RECTs endpoint-exclusive?

foo — Wed, 18 Feb 2004 22:19:00 GMT

Java uses the same scheme for substrings: myString.substring(start, end) where end is excluded. The length of the substring is simply (end - start). It's simple. I love it.

The problem is, Java substrings are so convenient that nearly every time I do string manipulation in C#, I curse the .NET-folks for using that old-fashioned (start, length) notation.

re: Why are RECTs endpoint-exclusive?

Simon Cooke [exMSFT] — Wed, 18 Feb 2004 22:42:00 GMT

Dan Maas:

X+0.5, Y+0.5 being the center of the pixel is only valid if you're using floating point graphics libraries such as GDI+, DirectX or OpenGL.

GDI and regular Win32 are integer, and so that definition doesn't really hold.

(Of course, GDI is fixed-point internally, but that representation doesn't generally make it out of the API).

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Wed, 18 Feb 2004 23:08:00 GMT

Sorry, CW, I don't know anything about metafiles. And sorry, Mike, I don't have any contacts in Windows CE (so I can't even verify whether the problem indeed exists).

Drifting off-topic...

Mo — Thu, 19 Feb 2004 00:13:00 GMT

Raymond, I have a question which you might be able to answer.

All of us good boys and girls who did our homework have known for years that NT's POSIX subsystem (and by association Interix/SFU) support fork() [for those that don't know: create a duplicate of a process, usually done in such a way that no/very few pages are actually copied until they're written to - called Copy-on-Write, or COW].

The Win32 API (as far as I can tell by RTFMing, Googling, newsgrouping, and generally given up trying some time ago) doesn't contain any equivalent - not even a closely guarded one. If I'm wrong, stop me now :)

Assuming I'm on-base up until now, the question is this: POSIX/Interix/SFU all need to get some kind of help from the kernel at some point along the way in order to actually perform the fork. After all, they're subsystems (or a subsystem, depending on how you look at it), not kernel-mode drivers, so they don't have much more access to the MM than I do in my Win32 process. By what mechanism do they get this "help" -- and how POSIX-specific is the help that they get? Specifically, would it be at all possible to utilize this support code - assuming it exists - from within the Win32 subsystem in order to achieve the same thing?

[Unsuprisingly enough, the fact that POSIX apps run in a different subsystem means they end up being really quite dull -- no "best of both worlds" for developers there]

Anyway, if you know the answer (or can point to some MSDN material that explains), I'd be very much appreciative. And apologies for a great big comment which bears practically no relation to rectangles :)

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Thu, 19 Feb 2004 00:16:00 GMT

Sorry, Mo, I have no idea. Gosh, people seem to be asking a lot of questions about things I know nothing about...

re: Why are RECTs endpoint-exclusive?

Dan Maas — Thu, 19 Feb 2004 01:03:00 GMT

Another off-topic question but maybe you can answer this... Is there an official policy on whether C++ exceptions should be able to propagate through Win32 API callbacks? i.e. if I throw an exception inside of a WndProc is it supposed to come out of the message loop or are the results "undefined"? I know this doesn't work with GCC on Windows but I am wondering what VC++ does. I assume you have to catch the exception before it propagates back out into Win32 code?

re: Why are RECTs endpoint-exclusive?

sd — Thu, 19 Feb 2004 01:06:00 GMT

Great article! I found this site through the aformentioned kuro5hin comment. I really dig the inside look at the Windows platform. Keep 'em comming!

re: Why are RECTs endpoint-exclusive?

Mo — Thu, 19 Feb 2004 01:12:00 GMT

Thanks anyway, Raymond. It was worth a try :)

I guess it's back to the drawing board with that one..

(I promise I won't use any undocumented APIs, though...)

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Thu, 19 Feb 2004 01:15:00 GMT

Dan: I can't think of an official policy off the top of my head against throwing C++ exceptions across Win32 callbacks, but my gut tells me nothing good can come of it...

re: Why are RECTs endpoint-exclusive?

Phaeron — Thu, 19 Feb 2004 03:43:00 GMT

Another disadvantage of inclusive rects is that you can't represent empty rects with them.

Simon Cooke:
Even with integer coordinates you still need pixel center rules for rasterization of certain primitives, such as solid ellipses. It is also possible to set scaling modes to gain direct access to 28.4 coordinates under NT GDI.

re: Why are RECTs endpoint-exclusive?

Pavel Lebedinsky — Thu, 19 Feb 2004 04:06:00 GMT

Re: fork() and SFU

http://weblogs.asp.net/jdzions would be a better place to ask this.

re: Why are RECTs endpoint-exclusive?

B.Y. — Thu, 19 Feb 2004 06:36:00 GMT

I agree endpoint-exclusive is a much better arrangement than endpoint-inclusive, but, I always wondered why the RECT structure have right/bottom instead of width/height, because rectangle's size and location are really two separate properties. And if you have width/height, you only need to touch left/top to move the RECT around.

And remotely related to this - I don't know if you know this Raymond - in multiple monitor support, why is it designed such that the sides of monitor RECTs only need to touch each other ? This makes things like centering a window on screen a major hassle, sometimes not even possible, it's theoretically possible to have 4 video cards positioned along the sides of the virtual screen, but leave a hole in the center.

Why wasn't it designed such that all video cards must form one big rectangle and cover all of it, and have the same bit depth ? Sure that reduces the flexibility, but it's a lot easier to program.

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Thu, 19 Feb 2004 07:33:00 GMT

right/bottom vs. width/height - it's a matter of style I guess. I happen to like right/bottom but then again I'm biased.

Multiple monitors: One could turn the question around. Why arbitrarily restrict all monitors to be the same resolution and be at the same color depth? In the early days of multiple monitors, the two video cards had very different capabilities. You had the onboard video that came with your motherboard (usually pretty lame) and a video card that you bought separately (pretty powerful). Forcing all video cards to be at the same resolution and color depth would mean that you would be running your expensive video card at some awful resolution like 800x600 because that's all the motherboard video could do. And then you'd be complaining, "I paid $200 for this video card. Why are you forcing me to run this pathetic resolution! Microsoft must be in a conspiracy with the video card manufacturers!"

And you shouldn't be trying to center on the virtual screen anyway. Pick a monitor and center on that monitor. If you try to center on the virtual screen, you will often end up with a window that is exactly cut in half by the two monitors, which is pretty useless.

Fork on Windows 2000

Christian — Thu, 19 Feb 2004 09:17:00 GMT

Look here:
http://www.cygwin.com/ml/cygwin/2002-02/msg00068.html

I own that book (Windows NT/2000 Native API Reference) and indeed it contains an example code that does a fork with copy-on-write

Command & message ids

Moi — Thu, 19 Feb 2004 09:56:00 GMT

Nothing to do with this article, Ramon, just an oddity I came across recently. In the MFC's AFXRES.H there are command ids for things like copy, paste, etc. and in WINUSER.H there are ids for messages which perform those types of actions (WM_COPY, WM_PASTE, etc.). Why are they not in the same order?

re: Why are RECTs endpoint-exclusive?

Mike Dimmick — Thu, 19 Feb 2004 09:59:00 GMT

On C++ exceptions in callbacks: if compiled with MSVC, a C++ exception is simply a Win32 SEH exception with code 0xE06D7363 (or 0xE0 'm''s''c'). IIRC, a pointer to the thrown object gets passed around in one of the SEH exception's parameters.

So the answer to Dan's question is whether an SEH exception can be successfully propogated through the Win32 API at this point. I think it probably can. MFC sets up a try/catch block in AfxCallWndProc (wincore.cpp) to stop exceptions propogating out of your message handlers, although this may be for debugging purposes. ATL doesn't bother.

re: Why are RECTs endpoint-exclusive?

Moi — Thu, 19 Feb 2004 10:01:00 GMT

Ramon? Sorry, Raymond, I guess my typing fingers are slacking. I shall punich them appropriately.

FillRectangle/DrawRectangle

hans — Thu, 19 Feb 2004 10:12:00 GMT

There is a difference between FillRectangle() and DrawRectangle(). FillRectangle() is endpoint-exclusive but DrawRectangle() is endpoint-inclusive.

Some sample-code:

private void button1_Click(object sender, System.EventArgs e)
{
Graphics g=System.Drawing.Graphics.FromHwnd(this.Handle);

g.FillRectangle(Brushes.Beige,30,30, 100,100);
g.DrawRectangle(Pens.Black,30,30,100,60);

Rectangle r1=new Rectangle(30,150,100,100);
Rectangle r2=new Rectangle(30,150,100,60);

g.FillRectangle(Brushes.Beige,r1);
g.DrawRectangle(Pens.Black,r2);

}

Both rectangles have the same width but the drawn rectangle is one pixel wider than the filled one... Why is this?

re: FillRectangle/DrawRectangle

hans — Thu, 19 Feb 2004 13:51:00 GMT

If you use FillEllipse() and DrawEllipse() there seems to be the same inconsistency. Maybe this applies to all Drawing-Functions.
Its especially apparent when using small values for width/height.

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Thu, 19 Feb 2004 15:47:00 GMT

Mike: Now I remember - throwing across a callback will often mess up the activation context stack. These sorts of bugs are incredibly hard to track down. You end up dying with STATUS_SXS_EARLY_DEACTIVATION or STATUS_SXS_INVALID_DEACTIVATION for no apparent reason.

Moi: You'll have to ask an MFC person.

hans: Um, that's some .NET thing isn't it. You should ask a .NET person.

re: Why are RECTs endpoint-exclusive?

Mike Dunn — Thu, 19 Feb 2004 15:51:00 GMT

Raymond, your mention of multiple monitors reminds me of something (and I think you can answer this one ;) )
A while ago you gave a great explantion of WM_NCCALCSIZE. Could you do the same for the MINMAXINFO struct? My specific problem is figuring out what to put in ptMaxSize. The docs only say "this refers to the primary monitor" which isn't much help.

re: Why are RECTs endpoint-exclusive?

Seth McCarus — Thu, 19 Feb 2004 16:24:00 GMT

And Raymond, since we sort-of got onto the topic of exception handling, can we expect your dissertation on it soon? That's one I'm looking forward to!

re: Why are RECTs endpoint-exclusive?

Andreas Häber — Thu, 19 Feb 2004 18:58:00 GMT

Raymond: Seems like the graphic code above (Hans' comment) is GDI+, so it's not only a .NET thing :)

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Thu, 19 Feb 2004 19:07:00 GMT

Okay, well GDI+ is less than 5 years old so I'm going to declare it "not old enough". :-)

re: Why are RECTs endpoint-exclusive?

Eric Lippert — Thu, 19 Feb 2004 19:49:00 GMT

Seth, if you want an excellent article on how exception handling works, try this one:

http://weblogs.asp.net/cbrumme/archive/2003/10/01/51524.aspx

re: Why are RECTs endpoint-exclusive?

Not actually a .NET admirer — Thu, 19 Feb 2004 22:37:00 GMT

> declare it "not old enough". :-)

Yes,

It says "The Old New Thing" and "not actually a .NET blog".

I don't know how to ask, but what I am trying here is something
like, in a way and sort of, heh, Raymond did you look at .NET stuff?
Or better, do you participate on it? Do you like it? Is there on
this blog or wherever some insight from you about .NET and
related technologies? Looks to me as if you are the only guy from
MS discussing good old Win32 stuff, while everybody else is
doing .NET.

PS. That's why I don't read any other programming blogs but yours.
If you go .NET, then I don't know what I'll do. I'll be lost!

re: Why are RECTs endpoint-exclusive?

Raymond Chen — Thu, 19 Feb 2004 22:47:00 GMT

Hey stop introducing more .NET content into this "not .NET" blog! I use it but I don't write about it.

re: Why are RECTs endpoint-exclusive?

Ben Hutchings — Mon, 23 Feb 2004 21:08:00 GMT

> Why wasn't it designed such that all video cards must form one big rectangle and cover all of it, and have the same bit depth ?

If your monitor screens aren't at quite the same height, you won't want the mouse cursor to jump up or down as it crosses between them. Well, I don't anyway.

Commenting on this entry has been closed.

Raymond Chen — Fri, 23 Jul 2004 07:02:00 GMT

Commenting closes after two weeks.

http://weblogs.asp.net/oldnewthing/archive/2004/02/21/77681.aspx

How to host an IContextMenu, part 10 - Composite extensions - groundwork

The Old New Thing — Wed, 06 Oct 2004 16:59:00 GMT

Preparing to combine multiple context menu extensions into one.

re: Bottom Right Exclusive Rects

The Old New Thing — Mon, 18 Oct 2004 18:43:00 GMT

Generating tooltip text dynamically

The Old New Thing — Thu, 29 Jun 2006 17:00:16 GMT

Using the TTN_GETDISPINFO notification.