Using Graphics.World when drawing

[johannblake]

I am wondering whether it is easy to setup a coordinate system for
drawing (using GDI+) that uses meters (or any custom scaling for that
matter). Currently, I need to convert from pixels to meters for
scaling. This can sometimes get rather complex when you need to take
scaling into account or other things like window resizing, scrolling,
etc.

There is a property called PageUnit which can be set to World. I could
not find any examples that illustrate how to use this "World" mode. Can
anyone show me a snippet of code how to setup the client drawing area
to work with meters?

In old VB, it was possible to create a custom scale. If I said that the
client area is 100 x 100, my app simply interpreted that as being
whatever I chose to define as the units. So if I drew a line 10 units
long horizontally (and assuming that the scale factor was set to one),
it would draw a line 1/10th the width of my client area. I am looking
for something along this line of simplicity.

Thanks for any help
Johann Blake

 

[Bob Powell [MVP]]

You can set the page units to millimeters. This gives each unit in world
space the value of 1 mm. Conversions to and from pixels are unneccesary.
Such conversion schemes can be a nightmare especially if you have to take
printing into account.

All zooming, panning and mouse input should be handled using a Matrix object
and you should simply paint all your object in their correct place in world
space coordinates.

See the GDI+ FAQ and Windows Forms Tips and Tricks for some ideas.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Frank Hileman]

World is only for specifying font sizes using world coordinates -- the same
coordinates as the current PageUnit and PageScale. World cannot be used as
the coordinate type for Graphics.PageUnit.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

 

[johannblake]

That is very strange that you should say that World cannot be used as
the coordinate type for Graphics.PageUnit. The PageUnit uses the
GraphicUnit enumeration which includes World as one of its members and
there is nothing that I was able to find in MSDN documentation that
indicates that it cannot be used.

 

[johannblake]

I actually do set the page units to millimeters. You mention:

"This gives each unit in world space the value of 1 mm"

What I discovered however is that this results in a line being
physically drawn on the screen in millimeters. This is not "world"
space, at least not the way most programmers envision world space.
World space is whatever a line length represents in the real world and
not how physically long it appears on a screen, which can be modified
with zooming factors.

What I am trying to avoid of course is any relationship between
physical lengths on the screen and the real world lengths that a line
length represents.

So if I want to draw a line that is a meter long but want it to appear
on the screen as 10 mm, I need to set ScaleTransform to some value that
scales from meters down to millimeters. The problem is, that a straight
meter-to-mm conversion isn't good enough. You need to take into account
the zooming factor. Why is that? Imagine displaying a single rectangle
on a screen. The rectangle is 10 meters wide by 20 meters high. If I
want the rectangle to fit exactly the height of the screen (such as in
Word with "fit to screen"), you need to apply a secondary amount of
scaling to the ScaleTransform and this can only be done by taking the
height of pixels of the client area into account. The client size
property returned in an OnPaint event gives its size in pixels and not
in millimeters (or whatever units you have set).

 

[Bob Powell [MVP]]

A trap that novices often fall into is to take zooming and panning into
account when doing drawing. This is entirely the wrong approach and causes
lots of problems because wherever you zoom or pan you must also unzoom and
pan back to deal with mouse interactions and so-on.

The correct technique is to set up a transform that takes care of your
zooming and / or panning and draw everything as if it were at 1:1 scale
allowing the display pipeline to put the pixels in the right place for you.

First apply a transform that copes with whatever level of zoom and pan you
need. Second, save the Graphics state either using Graphics.Save
(BeginContainer/EndContainer is broken) or using a home-grown matrix stack.
Third apply any other transform such as scale or rotation. Fourth, draw all
objects at 1:1 scale. Fifth, restore the graphics state back to the original
setting. Nesting states can give complex yet consistent drawing object
models.

The inverse of the matrix used to draw any specific object can be used to
"backtrack" the mouse from the current client coordinates to real-world
measurements in the graphics system.

See the GDI+ FAQ for more detail on all these subjects.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Johann Blake]

Hi Bob,

Actually I don't take zooming into account when drawing, that is, when
I call DrawLine, I don't factor in zooming. Zooming is done using
ScaleTransform and is only set once. After that, I do draw 1:1. But
when applying the initial transform, it is absolutely required to take
the client size into account which is always defined in pixels. I can't
see how it is possible to avoid this. Where things become rather
difficult has to do with scrolling and resizing. Any events raised as a
result of resizing or scrolling give you either a size or offset in
pixels that need to be converted over to real world coordinates. So if
you have a drawing that is larger than the client area and you have
AutoScrollMinSize set to allow you to scroll down the form to the part
not showing, you will still need to modify the transformation to pan
correctly.

What I have found very much lacking on the Internet is a simply
application that shows drawing in a units, like meters, that shows
zooming, panning, resizing and scrolling altogether. Almost every
example out there shows drawing on a form that does not include
scrollbars or take resizing into account.

 

[Frank Hileman]

Hello Johann,

Yes it is strange. The documentation is missing many things. In this context
World does not make sense -- World is not a true coordinate type, but rather
refers to the current coordinate type when performing drawing operations.
For example, if you draw a line, you can say you are using World
coordinates, which are interpreted according to the PageUnit/PageScale as
well as the current transformation in the Graphics. World means, "whatever
is current". So for a font size, you can see how it would be useful to
specify using World instead of Points -- the font size can be related to
other drawing operations.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor