xxxxx@gmail.com wrote:
Underlying requirement is display real time grid with many columns , rows at high FPS.
How high? I mean, let’s be realistic. If you have a grid with 20
columns and 40 rows filled with numbers, that’s 8,000 individual
entries. No human being is going to be able to extract anything useful
from such a grid if it updates faster than about 3 times a second.
A grid is a tough thing to optimize, because each string has to be a
separate call into the display driver, which means a user/kernel and
kernel/user transition. The display driver overhead is insignificant,
as is the hardware drawing time. You couldn’t do anything about that,
anyway.
Not benchmark itself . My boss says bottleneck comes from display driver or system , because GDI not accelerated enough in Windows 7 , as compare to directx . How to understand GDI performance limitation vs WM_PAINT process speed , etc ?
Your boss is smoking something. You’re talking about rectangles and
text. That’s not what people worry about when they talk about “graphics
acceleration”. There haven’t been any advances in that for a decade.
Do you actually have an application that is not responsive enough? Are
you using an off-the-shelf grid, or is it one you’ve designed?
May be benchmark not right approach . Really want to know , best way to achieve high FPS grid ?
Oh, a benchmark probably IS the right approach, but you need to be
looking at the whole application. I will bet you real dollars that any
bottleneck you find is in your grid control, and nowhere near the
display driver. You need to do some genuine profiling. Spend the time
to figure out exactly where your application really is spending its
time. There are good tools for that, and the results are usually
surprising.
Or which technology to use ? GDI, OGL, directX, direct2D, Qt ?
Qt adds yet another layer. It can make programming easier, but it
certainly will not improve performance. OpenGL sucks at text, as does
Direct3D. There is a new technology called DirectText that is designed
to work with Direct2D to allow more direct interaction with the graphics
card, but I firmly believe you would be wasting your time and money to
consider that step before you have done a thorough profiling to
determine where the time is really being spent.
Seriously. Programmers are TERRIBLE at guessing where the bottlenecks
are. I recently did a real-time telemetry application where it turned
out that 30% of the CPU time was being spent in the arctangent routine.
We were able to replace that with a table-based lookup, and the
application’s responsiveness went WAY up.
And yes, unfortunately, this is not really the right forum for this
question.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.