Re: howto avoid cdc drawing done not in onPaint to be erased?

See below...
On Wed, 11 Jul 2007 03:35:13 -0700, Equilibrium <ryariv@xxxxxxxxx> wrote:


Dave
--
David Webber
Author of 'Mozart the Music Processor'http://www.mozart.co.uk
For discussion/support seehttp://www.mozart.co.uk/mzusers/mailinglist.htm

Thanks Dave ,

I'll try to explain.
The reason i need all of this to perform outside the WM_PAINT message
is because the control is updated each 20ms with new object to
draw. the static control main goal is to display a tracking data , so
i recive x.y coordinates each 20ms , and on those coordinates
i need to draw something.
****
And how is this inconsistent with OnPaint? Why do you assume that it is "wasteful" when
you have no data to substantiate this?

For that matter, why do you think it is possible in Windows to update a window every 20ms,
when your thread could be preempted for hundreds of milliseconds?
*****

Storing those x,y in a string or an array and then caling WM_PAINT
(via invalidate) , and there to draw them, seems to me quite
expensive / wasteful , especially that the data can flow to the system
for along time.

In othere word what you are saying is, that if we are using the mouse
to free draw on a control ' we need to save each and every point the
mouse x,y position was.
*****
Well, in the case of an ellipse, you need only two points, so "each and every" is true,
but represents 2 points.

And the answer is, if you want to do a drawing, then yes, you need to store every point
required to do the drawing! There is no way to avoid doing this.
*****

What i need , basically is a way , when the disaplay need to be
"refresh\repaing" , to save the DC , and then restore it on WM_PAINT.
*****
A DC holds no display information; it holds the information required to CREATE the
display, that is, it guides the drawing, but it is NOT the drawing itself. So you would
not "restore the DC". You would issue the commands required to draw the pixels in the
OnPaint handler, otherwise the pixels can be lost and are unrecoverable. There's nothing
you can do to change this fundamental fact. Since you have no idea when the drawing needs
to be done, EXCEPT the OnPaint notification, you have no idea when something needs to be
redrawn.

Note that it is possible that drawing to a memory DC is slower, because drawing to a
memory DC probably cannot use the hardware accelerator features of the display card, which
typically write to the display memory directly.

By the way, it is reasonably safe to assume that your thread can be suspended, in serious
cases, for durations measuable in seconds, although small hundreds of milliseconds are
more common. So specifications about updating every 20ms are unlikely to be met (and
given that human reaction time is measured in hundreds of milliseconds, updating every
20ms seems like serious overkill anyway...and unless your device driver or hardware do
internal buffering, your chances of being able to successfully read data without lossage
is very small. This leads to other interesting architectures, such as using asynch I/O
and pumping dozens of ReadFile messages into the device driver so that you cna maintain
the data rate. Compared to this, the screen update is pretty minimal. Note that to make
any of this work well, you probably can't communicate with your device in the main GUI
thread, so the update issue is again problematice. Updating every few hundred
milliseconds is probably more than adequate, so perhaps a better approach is to simply
queue up all the data for display (creating the display list) but not invalidating, then
have a WM_TIMER handler that does an Invalidate() every 100-200ms or so, which draws
whatever data is available, and does so at human-compatible data rates. You're trying to
use conventional programming styles suitable for dedicated embedded systems in a
preemptible, event-driven, non-real-time operating system. This won't work.
joe
****

Thank you/

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Display the length of a drawn line in Visio 2003?
    ... Common Visio Questions http://www.mvps.org/visio/common_questions.htm ... of the page where the XY coordinates now display) automatically as I ... drawing the line so I can tell when to stop. ... I've done some more fooling around and if I draw a rectangle, elipse, ...
    (microsoft.public.visio.general)
  • Re: Display the length of a drawn line in Visio 2003?
    ... a shape that does this (a line with a text field specifing length...grow the ... works if you draw or select the line first, ... What I would like is for the length to display at the logical place ... drawing the line so I can tell when to stop. ...
    (microsoft.public.visio.general)
  • Re: Display the length of a drawn line in Visio 2003?
    ... Hey Vojo, that sounds cool. ... works if you draw or select the line first, ... What I would like is for the length to display at the logical place ... drawing the line so I can tell when to stop. ...
    (microsoft.public.visio.general)
  • Re: Display the length of a drawn line in Visio 2003?
    ... This posting is provided "AS IS" with no warranties, and confers no rights. ... works if you draw or select the line first, ... What I would like is for the length to display at the logical place ... drawing the line so I can tell when to stop. ...
    (microsoft.public.visio.general)
  • Re: Drawing on DC
    ... class Circle: public Drawing { ... It would be *called* from OnDraw, ... You should only draw when you need to draw, ... Drawing your objects on a bitmap merely renders the circle, rectangle, etc. as bits (which ...
    (microsoft.public.vc.mfc)