Screen refresh delay using wrefresh & mvwprintw

[Renda Skandier]

Hi,

I am getting a 4 to 8 second delay when trying to refresh a screen on a wireless device. The code works fine (& fast) on a computer terminal but after displaying the first 6 lines on my wireless terminal there is a 5 second delay before displaying the rest of the screen.

The same logic is used on multiple screens and all have the same delay. The wireless device is a Symbol scanner gun. Any ideas??

I am using HP ANSI C++ B3910B A.03.37
92453-07 linker command s800.sgs ld PA64 B.11.18 REL 000922

my makefile includes
DEFINES=-Dpa_risc -D_XOPEN_SOURCE_EXTENDED
INCLUDES=
INCD=../../inc
LDFLAGS=
CFLAGS=-Ae -g -I${INCD} ${DEFINES}
CC=/opt/aCC/bin/aCC
CP=/bin/cp
MV=/bin/mv
RM=/bin/rm

LIB=../../lib/toi/toilib.a ../../lib/crt/crtlib.a
TERM=-lcurses

My window structure is defined as
struct menu RFD010C[20] = {
{0, 1, 0x00,"ITEM : "},
{0, 2, 0x00,"PACK : "},
{0, 3, 0x00,"SIZE : "},
{0, 4, 0x00,"RETAIL: "},
{0, 5, 0x00,"STATUS: "},
{0, 7, 0x00," ENTER "},
{0, 8, 0x00,"[ ]"},
{0, 9, 0x00," "},
{0,10, 0x00," "},
{0,11, 0x00," "},
{END, END,0x00, " "}
};

WINDOW *ord;

/* Draw screen */
for(xx=0;RFD010C[xx].x != END;xx++) {
mvwprintw(ord, RFD010C[xx].y,
RFD010C[xx].x,"%s",
RFD010C[xx].text);
}
wrefresh(ord);

thanks in advance

[A. Clay Stephenson · Accepted solution]

I'm going to take a guess that this device has a relatively small input buffer. I would try moving your wrefresh() inside the for loop. Normally, this would make your code display more slowly but this just might do the trick for you. You might also play with
if ((xx + 1) % 4 == 0) wrefresh(ord);
inside the loop (and, of course, the final wrefresh() outside the loop).

I would also untic your terminfo entry and look for any large delays, indicated by N*, within any of the commonly used sequences -- especially "cup" (cursor address). You might be able to decrease some of those delays and tic the file.

[Renda Skandier]

Clay, Thanks for the input,
I tried moving the wrefresh and it didn't help much. I also tried using the for loop and it seemed the delay dropped a bit at 3 but it is still much too long.

Here is my untic... nothing sems obviously wrong to me.
HPISP> untic -/usr/share/lib/terminfo/v/vt220
vt220|vt200|vt220-nam|Digital VT220 w/no am,
eo, km, mir, msgr, xon,cols#80, it#8, items#24, vt#3,bel=^G, cr=\r, csr=\E[%i%p1%d;%p2%dr, tbc=\E[3g$<2>,clear=\E[H\E[J, el=\E[K, ed=\E[J, cup=\E[%i%p1%d;%p2%dH, cud1=\n, home=\E[H, civis=\E[?25l, cub1=\b,
cnorm=\E[?25h, cuf1=\E[C, cuu1=\E[A, cvvis=\E[?25h,dch1=\E[1P, dl1=\E[1M, smacs=\E(0, blink=\E[5m,bold=\E[1m, smdc=, smir=\E[4h, rev=\E[7m,smso=\E[7m, smul=\E[4m, ech=\E[%p1%dX, rmacs=\E(B,sgr0=\E[m$<2>, rmdc=, rmir=\E[4l, rmso=\E[27m,rmul=\E[24m, is2=\E[1;24r\E[24;1H, il1=\E[1L, kbs=\b,kdch1=\E[3~, kcud1=\EOB, kf1=\EOP, kf10=\E[21~,
kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf6=\E[17~,
kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, kich1=\E[2~,kcub1=\EOD, knp=\E[6~, kpp=\E[5~, kcuf1=\EOC,kcuu1=\EOA, rmkx=\E[?1l, smkx=\E[?1h, nel=\n,dch=\E[%p1%dP, dl=\E[%p1%dM, cud=\E[%p1%dB, il=\E[%p1%dL,cub=\E[%p1%dD, cuf=\E[%p1%dC, cuu=\E[%p1%dA, mc0=\E[0i,
mc4=\E[?4i, mc5=\E[?5i, rs2=\E>\E[?3l\E[?7l, rc=\E8,sc=\E7, ind=\ED$<2*>, ri=\EM$<2*>, sgr=\E[%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;
7%;%?%p4%t;5%;%?%p6%t;1%;m%?%p9%t\E(0%e\E(B%;,hts=\EH, ht=\t, kf11=\E[23~, kf12=\E[24~,kf13=\E[25~, kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~, kf20=\E[34~,el1=\E[1K,

[A. Clay Stephenson]

Nothing is glaringly obviously bad in your terminfo; however, the "MOD 3" wrefresh()'es being a bit faster makes me believe that we are on the right track - more or less. Here's my next whacko idea, at every 3rd line or so, do a wrefresh() to force output to the terminal but also add a nanosleep() of perhaps 0.1 seconds or so. My thinking is that whatever handshaking protocol the wireless device uses, the overhead must be rather expensive in terms of time. By artifically reducing the transmission rate, the display device is able to do less handshaking and avoid the overhead.

Whacko Plan B: If configurable, reduce the baudrate, this might really be a case where less is more.

Whacko Plan C: Call the equipment vendor and explain the problem.

[Renda Skandier]

I tried the nanosleep -- no change that I can see.

We use a telnet session to access the device, so there is no associated baud rate.

I have already contacted the vendor. They are sending us a sniffer package to see where the delay is.

Somehow, I still think it is in the code and the refresh sequence. I find it even stranger that at times, the delay is in word.
when displaying ITEM, IT will display then pause & continue with the EM. I agree there is something in the buffering but the exact spot of the delay is not consistant. The delay only happens once per screen, reguardless of whether it is on the 4th line or the 9th line; the rest of the screen displays quickly.
thanks again

[A. Clay Stephenson]

The fact that your code works well with a hard-wired terminal -- which I assume is also using the vt220 TERM setting argues strongly that there is not much room in the application for improvement. The bottleneck is in the wireless protocol. Stopping in mid-word strongly indicates handshaking overhead especially is the displays never lose characters or garble the output.

There is one more set of routines to play with. Rather than using wrefresh()'es try using wnoutrefresh()'es in conjunction with doupdate(). That will give you finer control over the curses window buffer vs the physical screen.

You might try using Gnu's curses library as a replacement to see if anything is handled better but this has all the signs of high handshaking overhead.

[Renda Skandier]

Clay, Thanks so much for all your help.
wnoutrefresh() & doupdate() made a huge difference.