Excel-like Input Screens (use Contools?)

[Michael Mattias]

we have to owner draw the cells different colors for different states and some cells are updated every 33 ms.

I'm sure your users appreciate that, as it gives them 33 updates each second.

It's just too bad they will miss 5-10 updates every time they have to blink.

MCM

[Chris Boss]

Elias,

When you say "double layer DC", do you mean "double buffering" ?

Double Buffering = drawing into a memory DC and then BitBlt entire image during WM_PAINT to screen

[Russ Srole]

Oh Michael, I knew you'd make some sarcastic comment. But here's a little secret for you. In regards to my customers and industry, you don't know jack s***!

As the Bard said "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Or as my wife might say, "Who asked you?"

Now on to the real subject. Elias, that sounds good. I'll log on to your site.

Thanks,
Russ

[Elias Montoya]

Elias,

When you say "double layer DC", do you mean "double buffering" ?

Double Buffering = drawing into a memory DC and then BitBlt entire image during WM_PAINT to screen

Yes, it uses double buffering, thats why it has no flicker.
im planning do add single buffering option for 4.0, for slower systems.
im still planning the design.

[Chris Boss]

Elias,

Rather than drop double buffering, I would suggest using the "dirty rectangles" technique to speed things up.

"Dirty Rectangles" is used by animation software to keep speeds high on slower systems.

It is quite simple.

Rather than invalidate the entire client area, when updates are needed, generate a region for only the areas which need updating and invalidate only that region. Then when WM_PAINT BITBLTs, the update region will be smaller and it will paint quicker.

For example, if a single cell or row is updated, then only invalidate the area that contains the row or cell.

Also when the client area scrolls, don't update the entire client area, but use the ScrollDC API to scroll and then update only the newly displayed row. ScrollDC is extremely fast.

Even on slower systems you can get good update speeds.

I also think that drawing directly into a window DC many items isn't going to be much faster than double buffering. It is very fast to draw into a memory DC compared to a window DC (screen). The BITBLT from a memory DC to a window DC is very fast.

[John Strasser]

I'm sure your users appreciate that, as it gives them 33 updates each second.

It's just too bad they will miss 5-10 updates every time they have to blink.

MCM

A bunch of years ago I wrote a series of screen driver classes for a client (I was still doing engineering systems then) where they wanted the screen to update as fast as possible to keep up with some testing machinery - apparently the screen was the bottleneck in how fast they could run the machine.

They wanted it to show each individual set of test results. //polishing fingernails - I waaaay exceeded expectations on that project \\ When I asked them why they wanted the screen to be a blur, their answer was so that when the rest of the system failed they would see the exact test number (and info) that it had failed on.

Granted, that *was* a rather specialized application...

JS

[Michael Mattias]

Biased, subjective, opinionated, unsolicited and more than likely gratuitous comment in re designing an application to perform 33 screen updates per second:

Prepare for your next job by practicing saying this:

"Would you like fries with that? For here or to go? "
"Would you like fries with that? For here or to go? "
"Would you like fries with that? For here or to go? "
...

[Elias Montoya]

...Rather than drop double buffering... .

No, im not. As i said, it will be an option, but the default i want it to be as it is now. But, remember im still planning it.

Rather than invalidate the entire client area, when updates are needed, generate a region for only the areas which need updating and invalidate only that region. Then when WM_PAINT BITBLTs, the update region will be smaller and it will paint quicker.

For example, if a single cell or row is updated, then only invalidate the area that contains the row or cell.

Also when the client area scrolls, don't update the entire client area, but use the ScrollDC API to scroll and then update only the newly displayed row. ScrollDC is extremely fast.

Even on slower systems you can get good update speeds.

I also think that drawing directly into a window DC many items isn't going to be much faster than double buffering. It is very fast to draw into a memory DC compared to a window DC (screen). The BITBLT from a memory DC to a window DC is very fast.

Thats how Egrid32 worked in earlier versions and it was great. Except that
the new features require more than that.

For example, there is an option for background that stays in the same place
and only the grid contents are scrolled...

There are some situations like this, that force a complete screen refreshment. Thats why i plan to add single buffering feature as well as the
behaviour that you (Chris) suggest.

[Russ Srole]

Michael,

Oh the arrogance of ignorance! I've been updating screens 30 times per second for over twenty years, and I get paid real money to do what I do.

Now, since you believe you are so clever, let's see if you can figure out what industry deals with something that changes 30 times per second.

A couple of hints:
1 - Your customers would have no use for such a device.
2 - When you kick back at the end of a long day and stare at glowing screen.....

[Russ Srole]

Elias,

Chris Boss had the listview answer.. But don't despair, one day I'll need a real grid control and Egrid will be the one for me.

Russ

[Michael Mattias]

I did not say "dealing with" something thirty times per second was wrong; indeed, as you point out, it is often necessary.

True, you may at some point want to display the details of what happened (past tense) at that speed; however, while I have no hard evidence or scientific studies to cite, common sense tells me no human being can possibly read 33 updates each second.

Therefore, trying to display 33 screen updates per second in real time without 'flicker' is totally silly goal, since 'real-time-ness' is totally useless.

Assuming a detailed log of something which happens this quickly is desired - and well it might be - I'd either accept the flicker or find another way... eg write activity records to disk or memory and load up the display either at the conclusion of the operation or as a background operation.


MCM

[Brad D Byrne]

I'll bet Russ is into video editing & compression

[Russ Srole]

Brad,

Very good. Not editing at this particular time, although I made linear editors (video tape) from the mid '80s until the late '90s and broadcast non-linear (disk/server based) for a number of years. But you have nailed it close enough.

The reason to display 30 fps is that the customers expect to see updates in real time. If you display timecode every other frame it just looks crappy and amateurish. If that's how others want to make product it's ok with me, but I prefer to do things in a professional way.

[Elias Montoya]

Hey Russ, no worries! Its good to know it worked.
And your app sounds interesting!

[Russ Srole]

Elias,

Yes, it's been an interesting and fun project. I can't say too much as I'm under NDA (non-disclosure agreement). When they're ready to release, I can point to the url.

Russ