Re: [ntdev] test display driver performance

I will suggest that you look at two parts of your problem:

Is the data grid data bound? If so, most likely your issue is with processing the updates. Look at coalescing them via disabling the automatic updates thru the binding source

If you have not already, evaluate owner drawn controls. You can drive dramatic performance if you avoid the pedantic sub contracting that happens with standard drawing

Sent from Surface Pro

From: xxxxx@gmail.com
Sent: ‎Friday‎, ‎December‎ ‎12‎, ‎2014 ‎3‎:‎38‎ ‎PM
To: Windows System Software Devs Interest List

Hi , Roberts ,

Underlying requirement is display real time grid with many columns , rows at high FPS . 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 ?

May be benchmark not right approach . Really want to know , best way to achieve high FPS grid ? Or which technology to use ? GDI, OGL, directX, direct2D, Qt ?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Did you read my previous post?

You need to look at either data bindings (if they exist) and or making your control owner drawn

That is how you can control the WM_PAINT flooding you are worried about. As I said, the default rendering of a DGV requires pedantic 'subcontracting’ of regions and therefore results in poor graphics perf

Sent from Surface Pro

From: xxxxx@gmail.com
Sent: ‎Sunday‎, ‎December‎ ‎14‎, ‎2014 ‎2‎:‎10‎ ‎AM
To: Windows System Software Devs Interest List

Hi , Roberts ,

Not all grid cell changing every time . Some most of time , a few some of time , some infrequent . Invalidate() was for worst case test . Can optimize with draw smarter . But must avoid flood WM_PAINT from many small Invalidate ( Rect ).

I perform second test as follow . Recall , old test , draw string with Graphics.DrawString in OnPaint , use 25 % CPU ( 100 % one core ) , window jerks .

New test , create 1,000 Bitmaps at startup , draw random strings into . In OnPaint , select Bitmap at random , copy to Graphics with FillRectangle ( TextureBrush ) . CPU 5 % this test . Therefore , TextureBrush blit faster than GDI+ draw string ?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Is your application single threaded or multi-threaded? If you have multiple top level windows (one per screen say) you can use multiple threads to spread the work out without making any other changes in your code.

If you can keep track of the validity yourself, then you can use the standard grid, but make the

Client area owner drawn and bitblt it from a memory dc. The memory dc can even be updated from multiple threads if your data arrives that way, but make sure that the updates get coalesced. At least so that they don’t exceed the refresh rate of you monitor even if you don’t want to add some extra delay for human consumption

If you can’t keep track of the validity, then you will need a custom grid. There are several available on the internet of various quality that you can buy, or you can write your own. Bitmap caching and other fancy tricks will improve your perf, but probably not significantly. The main problem will continue to be state management of the validity of the various cell rects

Sent from Surface Pro

From: xxxxx@gmail.com
Sent: ‎Monday‎, ‎December‎ ‎15‎, ‎2014 ‎1‎:‎42‎ ‎AM
To: Windows System Software Devs Interest List

Hi , Shatksih ,

Do not mean to offend .

Grid has real time data source . Not database , bound data source etc . Actual , user don’t scroll much at all . Screen size large enough to display most useful data . Also multiple screen .

Agree user cannot see content of many cell at fast update rate . However , also have feature : conditional paint , background cell color , highlight cells , etc . Pattern of highlight across grid etc . very important to user , during fast update . Give feed back more than actual cell value .

Seems , must implement own grid , not use .net dgv. But , many codes to implement : bitmap cache , accept user input , resize column , reorder column , … boss wants quick fix !!


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

So your application is nearly exactly as I suspected.

In GDI, validity means whether or not the pixels in a certain region are still valid with respect to the window that owns them or the need to be refreshed.

When using a DGV, each cell is a sub-control and each one is validated and painted on its own. That is just fine for static data. And works well for updates that users will actually read, but the data rates you are talking about are beyond its normal use.

As you have no data bindings, your case is simpler. Instead of calling UpdateCellValue and shunting an invalidate call followed by a paint operation via the message pump, you should make the client area owner drawn and use a technique called double buffering. This is typically used to avoid flickering, but in your case, instead of locking some data structure (or in addition to looking the data structure) to update data, lock a memory device context (or a portion thereof) and paint to it in the worker thread that receives the update. After an update had been processed, use WM_INVALIDATE or the equivalent .NET call to force a re-paint. Importantly, don’t trigger another paint until the last one is complete (plus any delay for a human to read it). This can’t be made to work perfectly without a reliable timer (impossible on a preventive OS like Windows) but a good approximation I easy. And assuming that ordinary people can’t actually detect delays in the 10-20 ms range, you have nothing to worry about

Sent from Surface Pro

From: xxxxx@gmail.com
Sent: ‎Monday‎, ‎December‎ ‎15‎, ‎2014 ‎1‎:‎39‎ ‎PM
To: Windows System Software Devs Interest List

Hi , M M ,

App is multi - threaded . Data come from 4 - 5 sources , every source run on own thread . Thread code put data in backing store , then call UpdateCellValue() . But , how to use existing grid “multi thread” ? Have to call UpdateCellValue() , then grid ask for cell value later in CellValueNeeded , called from " GUI thread " . This is bottle neck , I think . Do you mean , run every grid as separate process ? Use IPC to control ?

I don’t get your meaning , " keep track of the validity yourself " . Do you mean , know which cells need repaint ? How is different from know when to call UpdateCellValue ?

I thought , test showed , fill blank rect or fill rect with bitmap , fast , but write cell string with GDI+ , slow . Thus , propose cache cell bitmaps . Not needed ? Shatskih think , yes.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer