🚀 go-pugleaf

In article <1992Oct16.011314.2273@emr1.emr.ca>, jagrant@emr1.emr.ca (John Grant) writes:
|> When I paint my client area in response to WM_PAINT, I scale my 'world'
|> co-ordinates (~1e6 metres) to logical units of 0.1 mm and then paint with
|> MM_LOMETRIC.  This is fine.  Up until now, I have ignored the clipping
|> rectangle in PAINTSTRUCT, just to get it working (slow).  Now I want to use the
|> rect to redraw only what is required.
|> 
|> Now I'm confused about how to use this clipping rectangle because it is
|> provided for the default hdc of MM_TEXT and I work in MM_LOMETRIC.
|> How do I convert those MM_TEXT co-ordinates to MM_LOMETRIC co-ordinates?
|> I thought of using screen co-ordinates as an intermediate, i.e.:
|> 
|> [WM_PAINT code omitted]
|>
|> Is this the correct way to do this?  I was hoping there would be a more
|> transparent way.

Well, MM_TEXT *is* device coordinates so you probably don't have to do an
LPtoDP first.  I think, though, that your approach is what is needed.
Since you can't setup the mapping mode in the DC until you get the paint
message Windows obviously cannot give you the invalidated rectangle in your
coordinates so it does it in pixels.  Your responsibility to convert as
necessary to logical units.

|> 
|> Preferences...
|>   It appears that there are several cases where a redraw is required:
|> 	(a) WM_SIZE/WM_PAINT
|> 		Since the window has changed size, the only way to
|> 		do this is to read the data all over again and redraw the
|> 		whole client area from scratch.  True?

If you scale the picture to fit in the area, yes -- always true, unless you
want to try a StretchBlt in line with the BitBlt idea below (*not*
recommended!)


|> 	
|> 	(b) WM_MOVE/WM_PAINT (possibly not as common)
|> 	(c) WM_PAINT after an occluding window is removed
|> 		If I BitBlt a copy of the picture to memory after each
|> 		WM_SIZE/WM_PAINT or initial WM_PAINT, then I could repaint
|> 		a part of it by just BitBlting from memory to the client area?

Yes indeed!  This can be a big win if the act of drawing the picture is
computationally expensive.


|> 
|> Is it better to redraw the rectangle by reading the data and drawing it again
|> or attempt to BitBlt the picture to memory the first time, so that subsequent
|> times it can be redrawn with more BitBlts.  Is the BitBlt seamless?

1/2 of one, 0.5 of the other.  The operation of BitBlt ultimately depends on
the display driver, but in general is fairly seamless.


----------------------------------------------------------------------------
Tom Brown               |  "Strange women, lying in ponds, distributing
PE Nelson Systems       |   swords is no basis for a system of government."
twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------