Anyone on here a really good '**** client' graphics developer?

Walt - KZ1F

There are some subtle nuances of client side graphics programming I'd like to find someone to discuss this with. This will be really advanced high performance type stuff. If it were the late 80's Windows world, I wouldn't need to ask but its not, so I do. Thanks! Walt

Mark_WS7M

Hi Walt,

Are you looking for help?  And in what language?  I'm a device programmer but over the years I've been yanked into the WPF world kicking and screaming.  Send me an email and we should talk:  ws7m@arrl.net

Walt - KZ1F

Not so much help. I, pretty much ended my graphical Windows programming late 80s, pre MFC. Back then there were 'optimizations' on could make with regard to scrolling. Specifically, your program would capture the wm_scroll event, you would then issue a winscrollwindow to scroll from y=1 to Ymax-1. You'd then wininvalidatewindow the entire width of y=0. Or you could redraw the entire window. The facilities now, be it android, or javafx8 or, best I can tell, WPF, simply leave no apparent option but to redraw the entire window. This appears to be what ssdr does and is what XPSSDR does. XPSSDR runs under 2% CPU so there is no, apparent, performance issue but it feels to me an awful lot of unnecessary work is being done. So it isn't tied to language, rather graphics technology.

Oh, the wininvalidatewindow would trigger a wm_paint message for the one Pixel height of the control. The advantage of this can be seen in the speed difference between running tail -f in a maximized window vs a window 2 lines in height. When I said graphical I wasn't referring to buttons, labels, sliders, etc.

Mark_WS7M

Got it.  I think these days graphics cards have basically their own CPUs so dumping a bunch of data into the card and letting it deal with it is kind of the current mode.

We have an image analysis program that examines very high resolution pictures of stained skin samples on slides.  One of the general algorithms is to run an FFT on a column or row of pixels.

Our first pass at the software did it in our code which worked ok but these images were very big, 10mb + sometimes much more so it took some time to get through FFT of all rows and columns to build that backplane data we needed.

We we hired an image analysis expert and he had us go out and buy some very expensive video cards with a ton of RAM on them.  I worked with him over about a month to move the FFT processing into the GPU.  The results were pretty amazing.  We could load up a 10mb image file and run all the row/column FFTs in less than a 1/4 of the time it took to do them on the computer CPU and all the while the computer was loafing along at 1% CPU.  Before this it was maxed out.

So ya... there is so much now that you can do with newer vid cards and GPU chips.

Walt - KZ1F

Oh, I completely agree, today's video cards are much more powerful than they were 20-25 years ago. But, in the for instance above, the WinScrollWindow would translate to a GPU bulk memory move, which it can do very efficiently, followed by a paint of a single row of pixels, as opposed to multiple thousands of them. That's always been kind of a Ying and Yang of software development, does an organization spend the money to make a program faster, ergo less expensive to run, or simply wait for IBM or Intel to solve the problem, with the next generation of hardware. My philosophy has been do more with less. I'll email you, as this is going to go into the weeds.