Prev: proper way to close a socket?
Next: DrawText and measuring offset strings
From: Scott McPhillips [MVP] on 8 Mar 2010 15:54
"dan" <dan(a)nospam.com> wrote in message
news:eTxfAquvKHA.5340(a)TK2MSFTNGP04.phx.gbl...
>
> "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
> news:OuDOSqtvKHA.4908(a)TK2MSFTNGP06.phx.gbl...
> [...]
>>
>>
>> There are a couple of possible ways to use timeSetEvent (which comes in
>> on a system thread) and still do your painting in your main thread. The
>> first is to call Invalidate on your window's HWND from the timer thread.
>> That will cause a WM_PAINT. It's debateable whether Invalidate accesses
>> the window from the thread, but in my experience this is thread safe.
>>
>> Another possibility is to simply PostMessage or SendMessage a
>> user-defined message (WM_APP + n) to the HWND. The message handler in
>> the main thread (use ON_MESSAGE in the message map) can then do
>> Invalidate or even paint directly. The advantage here is that the
>> WM_APP+n message is not low priority like WM_TIMER, so you will get a
>> more consistent frame rate than WM_TIMER can give you.
>>
>> --
>> Scott McPhillips [VC++ MVP]
>
> Scott,
>
> Thanks for the reply.
>
> I think that calling Invalidate() would be ideal but since I cannot be
> absolutely sure that it is thread safe then I need to stay away from it.
> If, for example, I get a report about the app locking up once a week (or
> even month) I will always tend to think that Invalidate() is the cause.
>
> I was also considering PostMessage() in the past but was afraid that this
> would flood the message queue. Do you see any problems with posting ~30
> WM_APPn messages a second?
>
> As per my original post, is there a way that I could override CWinApp's
> Run() method and use QueryPerformanceCounter() to drive animations? Or,
> is this approach not recommended for mfc apps?
>
> Thanks,
> Dan
>
>

PostMessage at 30/second certainly won't flood the message queue if you are
processing the messages. And if the message handler does nothing except
Invalidate() then there's no harm done even if a number of messages build up
in the queue.

Overriding the Run() method with QueryPerformanceCounter-based timing would
be the way to go if you want really smooth animation. Gamers do it that way
(not that they use MFC much). You might have to rewrite the Run() method to
use PeekMessage instead of GetMessage to keep your animation running full
time. If you want that quality level then you should pretty much forget
about WM_PAINT and draw at regular intervals. The only downside is you
gobble up CPU cycles spinnning at QueryPerformanceCounter.

There is no issue of this being "not recommended" for MFC apps: Run() is
virtual so you can do this. But at some point down this road MFC stops being
relevant!

--
Scott McPhillips [VC++ MVP]

From: Jerry Coffin on 8 Mar 2010 20:36
In article <OiClr2svKHA.5340(a)TK2MSFTNGP04.phx.gbl>, dan(a)nospam.com
says...

[ ... ]

> I did have a look at timeSetEvent (and the newer QueueTimerEvent)
> but at the time I thought that it would not work for me. The
> primary reason being that the timer callbacks would take place on a
> different thread than the thread that created the target window.

That's true. As Scott pointed out, you generally don't want to do the
drawing directly from the timer call-back, but you can post a message
to your main thread. Posting a WM_PAINT works perfectly fine.

Contrary to popular belief, WM_PAINT isn't really a low-priority
message -- if you post a WM_PAINT to the queue, it'll be processed in
order just like any other message.

The reason people think it's low priority is because a WM_PAINT will
only (normally) be seen when there are no other messages to process.
That happens because InvalidateRect doesn't directly generate a
WM_PAINT message. Rather, it sets a flag attached to the message
queue that says the window has an invalid rectangle. If the queue is
empty when GetMessage is called, it'll then look at that flag, and if
it's set, it'll synthesize a WM_PAINT message and return it.

If you put a WM_PAINT into the queue, however, it'll be processed in
order, just like any other message would. Picking a different message
number won't hurt anything, but won't really help either.

--
Later,
Jerry.
From: dan on 10 Mar 2010 12:05

"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:u$qaWGwvKHA.4492(a)TK2MSFTNGP05.phx.gbl...
[...]
> But at some point down this road MFC stops being relevant!
>
> --
> Scott McPhillips [VC++ MVP]

What framework would you recommend then for a new app that renders 3D
animations and [possibly] plays media files? Would you recommend to go
native C/C++ or managed C#? If former, what 'relevant' framework can be
used? If latter, would you know of any issues (performance and/or
development related) with Direct3D and playback of media files?

Thanks


From: Jerry Coffin on 11 Mar 2010 09:11
In article <uxNumPHwKHA.5812(a)TK2MSFTNGP02.phx.gbl>, dan(a)nospam.com
says...

[ ... ]

> What framework would you recommend then for a new app that renders
> 3D animations and [possibly] plays media files? Would you
> recommend to go native C/C++ or managed C#? If former, what
> 'relevant' framework can be used? If latter, would you know of any
> issues (performance and/or development related) with Direct3D and
> playback of media files?

I'd definitely go with native code.

There are quite a few frameworks for high-performance 3D code, though
exactly what they cover varies pretty widely.

On the extremely lightweight end is GLFW -- basically, it handles a
few things like setting up a window that plays host to OpenGL, and
gives reasonably portable access to keyboard and mouse input.
That's about it though. With it, nearly all your drawing is done with
straight OpenGL calls.

OpenSceneGraph is quite a bit larger and "heavier". It has built in
support for widgets, terrain, particle systems, shadowing, text, etc.
This does have the nice point that you can use it along with MFC to
at least some degree. At least to me, it seems like it's really
oriented more toward scientific uses than games though. In case
you're wondering, a "scene graph" is referring to building a graph
(the data structure, not graphics) of the scene -- i.e. basically a
tree-like structure that lets you say (for example) that these twenty
objects are all red colored, and of those, ten look like plastic,
five like rubber, one is metallic, and the rest have a brick texture.

Ogre3D is oriented a lot more toward games. It's also big -- the
library itself is big, *and* it depends on some other libraries as
well (Freetype at a bare minimum, but a half dozen or so are
recommended). As a result, you can probably plan on around a solid
day of work getting it installed and built just to the point of being
able to run a demo program. The other side of that is that it
includes a lot, and it's pretty cleanly designed and put together, so
you get access to a lot of capability pretty cleanly.

--
Later,
Jerry.
From: dan on 11 Mar 2010 12:00

"Jerry Coffin" <jerryvcoffin(a)yahoo.com> wrote in message
news:MPG.2602470c49f8ab1a98984c(a)news.sunsite.dk...
> In article <uxNumPHwKHA.5812(a)TK2MSFTNGP02.phx.gbl>, dan(a)nospam.com
> says...
>
[...]
>
> I'd definitely go with native code.
>
> There are quite a few frameworks for high-performance 3D code, though
> exactly what they cover varies pretty widely.
>
> On the extremely lightweight end is GLFW -- basically, it handles a
> few things like setting up a window that plays host to OpenGL, and
> gives reasonably portable access to keyboard and mouse input.
> That's about it though. With it, nearly all your drawing is done with
> straight OpenGL calls.
>
> OpenSceneGraph is quite a bit larger and "heavier". It has built in
> support for widgets, terrain, particle systems, shadowing, text, etc.
> This does have the nice point that you can use it along with MFC to
> at least some degree. At least to me, it seems like it's really
> oriented more toward scientific uses than games though. In case
> you're wondering, a "scene graph" is referring to building a graph
> (the data structure, not graphics) of the scene -- i.e. basically a
> tree-like structure that lets you say (for example) that these twenty
> objects are all red colored, and of those, ten look like plastic,
> five like rubber, one is metallic, and the rest have a brick texture.
>
> Ogre3D is oriented a lot more toward games. It's also big -- the
> library itself is big, *and* it depends on some other libraries as
> well (Freetype at a bare minimum, but a half dozen or so are
> recommended). As a result, you can probably plan on around a solid
> day of work getting it installed and built just to the point of being
> able to run a demo program. The other side of that is that it
> includes a lot, and it's pretty cleanly designed and put together, so
> you get access to a lot of capability pretty cleanly.
>
> --
> Later,
> Jerry.

Jerry,

Thanks again for the reply.

The app that I'll need to work on soon is not that heavily into 3D stuff.
The playback of media files and 3D rendering is just one of many
requirements. But this particular requirement is very important and the 3D
rendering must be very reliable and smooth. The app will have standard
Windows UI elements (e.g. menus, toolbars, etc.). The 3D rendering and
media playback will take place in client area of a window.

I think I'll need to go with Direct3D and not OpenGL because I might need
some interaction between Direct3D and video renderers while playing media
files.

I would be very happy with MFC and its CView derived window as a rendering
target as long as I will not have to 'fight' the framework while doing
something that might be trivial in a non-mfc app (native or managed).

Thanks.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: proper way to close a socket?
Next: DrawText and measuring offset strings