Screen write only happens when reading a key

[wmcbrine]

Screen write only happens when reading a key

[wmcbrine]

Actually it updates on idle (napms), but of course that's also called from getch(). Anyway, I see your point.

[wmcbrine]

Tentative fix for X11 -- please let me know it if works for you:

6503aa9

SDL is going to be harder...

[wmcbrine]

OK, please try both now.

[rexx-org]

Thanks for looking at this so quickly. I've had mixed results... With commit 492b402. All my tests on Linux so far.
With the small test program I wrote (attached), both x11 and sdl2 work fine; under most circumstances. The test program reads text from a file, displays the text and sleeps for 5 seconds.
The SDL2 version has a problem if you switch desktops between each line being displayed. The contents of the screen is overwritten with the contents of the previous desktop on return to the demo program. This does not happen when any SDL2 curses program is waiting for a key, presumably because it can process all outstanding events. The x11 version of the demo program works fine even between desktop switches.
With THE, which does far more complicated curses manipulations than the demo program, I get correct screen refreshes on both x11 and SDL2 if I don't switch desktops. However I get a blank (all black) window when I switch desktops with the x11 version. The SDL2 version of THE has the same problem with the demo program on desktop switches.
demo.zip

[wmcbrine]

OK, the desktop switching problems are a separate issue. So far, I can't reproduce that. Can you provide more details about your system?

[wmcbrine]

The closest I can get to reproducing the second issue is if I minimize the SDL version of your demo, and then restore it -- I briefly get a "not responding" pop-up. This goes away if I replace sleep(5) with napms(5000).

[rexx-org]

I've replicated the display issue with switching desktops on the only 2 systems I've tried; so a 100% success rate of replication. First system is Ubuntu 18.04, second system is Raspberry Pi running Debian Buster.
Have the other desktop (the one not running the demo program), is displaying some window contents like a browser. Start demo in the first desktop, switch to the second desktop and then switch back to the first desktop where demo is running. The contents of the demo window will contain that portion of the second desktop. When the next line is read from the file, it is displayed over the top of the demo window (which still contains the second desktop contents). It isn't until the last line "press any key to continue" is displayed that the demo window is cleared to a black background. The above description of behaviour is for SDL2 version. The x11 version overwrites the demo window with a black screen instead of the second desktop contents.

[wmcbrine]

Yeah, no, it still doesn't do that for me (Ubuntu 19.04). Reason I asked for more system details -- wondered if it might have to do with particular video drivers or something. (I saw terrible problems with screen updates -- not specific to PDCurses -- under VirtualBox, which vanished running the same OS natively.)

I had an idea to fix it anyway, but it failed to fix the "not responding", so back to the drawing board...

[rexx-org]

My Ubuntu system is quite old and am using video drivers that are quite old. However the Raspberry Pi is new; Model 4 B+ and running latest Raspbian, so video drivers should be up to date.

[wmcbrine]

So, I got a Raspberry Pi 4 -- not for this, but anyway -- and I finally did reproduce the issue. :) And I tried my speculative fix, and then took it a bit further. It works, but with the demo as posted, it still takes until the next write to restore the screen. If you replace sleep(5) with napms(5000), it's restored within 50ms. I believe this is as far as I can take it without a major restructuring. (SDL docs warn against calling SDL_PumpEvents() from a second thread.)

[rexx-org]

I applied this fix to my development machine; Ubuntu 18.04 and rebuilt THE. Unfortunately the fix severely broke all PDCurses programs. If you run a PDCurses program (like tuidemo) in one desktop, then change to another desktop and then back again, the PDCurses program now contains the contents of the previous desktop and nothing can be done to restore the PDCurses program contents. Now to work out how to revert a commit in git :-)

[wmcbrine]

Can you at least confirm that it works on the Pi?

I don't understand your issue, but again, if you could give me more detail on the system in question beyond that it's "quite old", it might help. Also, and not that it should be necessary, but have you tried newer versions of Ubuntu?