views:

36

answers:

2

Hi.

I have a Process Control system. It has a huge 2D workspace where all the logic is laid out. The 2D workspace is a coordinate system. You usually do not see the whole workspace at once, but rather some in-zoomed part of it focusing on some part of the controlled process. Such subsystem views are bookmarked into predefined named images (Power Generator1, Diesel Generator, Main lubrication pump etc).

This workspace interacts with many legacy MFC software components that individually contribute graphics onto the workspace (the device context is passed around to all contributors).

Now, one of the software components renders AutoCAD drawings onto the surface. However, the resolution of the device context is not sufficient for the details of this job. The device context logical resolution is unfortunately dictated by our own coordinate system, which at high zoom levels is quite different from the device units (pixels). For example, a line drawn using

DC.MoveTo(1,1); 
DC.LineTo(1,2);

.... will actually, even though it's drawn directly onto the device context by increment of just one logical unit, cover quite some distance on the screen. But the width of the line would still be only one device pixel. A circle looks high res, but its data (center point and radius) can only be done in coarse increments.

I have considered the following options: * When a predefined image is loaded and displayed, create a device context with a better suited resolution. The problem would then be that the other graphic providers interact with it using old logical units, which when used against the new DC would result in way too small and displaced graphical elements.

  • I wonder if I can create some DC wrapper that accepts both kinds of coordinates through different APIs, which are then translated into high res coordinates internally.

  • Is it possible to have two DCs with different logical/device unit ratio? And render them both to screen?

I mentioned that a circle is rendered beautifully with one pixel width even though it's placement and radius are restricted. Vertical lines are also rendered beautifully, even though the end points can only be given in coarse coordinates. This leads me to believe that it is technically possible to draw in an area that in DC logical coordinates could only be described in decimals.

Does anybody have any idea about what to do?

+1  A: 

You need to scale your model, not the device context.

Hans Passant
Thank you for responding.The device context should definitely **not** have logical resolution decided by the geographical model area that is displayed. The problem is the legacy usage of the common DC by all the other legacy components, which is quite a handful. I am looking for a solution which minimizes the impact on drawing logic for the other components.I am considering making the DC wrapper that wraps a high res DC, with legacy API still accepting coarse model coordinates, but adding overloads that support decimals. There will still be rounding errors, but much less so.
Tormod
+1  A: 

You could draw the high-def image to another DC in a new window and place that window over your low-res-drawing. Of course you have to handle clipping yourself.

dwo
How about transparancy? The various components provide different element types (one provide static texts, one provide process symbols, one provide live data). These elements are all over the place and can overlap (measurement within a symbol etc). They are primitives, not separate controls. Can one hi-res DC draw transparently on top of the rendering of the other?
Tormod
Transparancy would be possible with BitBlt-ing, but this leaves the problem of z-order. In this case your idea of writing a special DC which converts low-res-coordinates to high-res sounds better to me. Do you use MM_LOMETRIC and MM_HIMETRIC or other ones?
dwo
I do not think so. I assume the mapping mode is "Text". Actually, I've never fiddled with that. Is there something there for me?
Tormod
Here is some info on mapping modes: http://msdn.microsoft.com/en-us/library/hzy9cbxf%28VS.80%29.aspx
dwo