I noticed that function clear() retransmit all screen to terminal instead of transmitting only the differences, as excepted with ncurses.
I'm working with SSH so I can see the difference on a 180x60 terminal :
with clearing using clear() : 20kB/s
without clearing : 200B/s
The refresh rate is 0.5s and the differences between each frame is about 20 characters.
How can we explain this and clear screen more efficiently ?
From the man page:
The clear and wclear routines are like erase and werase, but they also call clearok, so that the screen is cleared completely on the next call to wrefresh for that window and repainted from scratch.
Try erase()
Related
I'm developing serial terminal sw and trying to resolve asynchronous screen size.
Below is in detail
There are modem_[a,b] and modem_a's uart1, _b's uart0 are connected(Main console port of both is uart0).
serial_app on modem_a attempts to access to modem_b via serial line.
serial_app uses termios library
And it's possible to serial-access to modem_b then it provides terminal service like putty.
But I change console window size then it starts asynchronous display.
However, I execute resize command then it becomes fixed.
So I checked SIGWINCH and it was triggered on modem_a but not on modem_b. And I've looked for how to pass SIGWINCH through serial terminal or cause SIGWINCH over modem_b controlling terminal settings like ioctl_tty(), escape sequence(\e[8;$Height;$Width, ...) , and so on...
Eventually I failed..
I'd like to maintain synchronous display whenever I change window size.
So you guys, Do you have a solution? or anything else?
I found out why I was unable to automatically synchronize window size and display on serial terminal. It's just there is not a mechanism on serial terminal.
So, we should manually synchronize window by resize command on that.
Reference:
source : http://lists.busybox.net/pipermail/busybox/2009-May/069226.html
source : https://wiki.archlinux.org/index.php/Working_with_the_serial_console
I was making some modifications in the linux kernel, and something has broken due to my changes, I have lots of printk's inside the code, which do show up only in the tty console (Ctrl+Alt+F1) .
The problem is that it quickly keeps moving down and reaches the kernel crash info and I cannot determine anything from the crash info as everything is lost after a reset.
Is it somehow possible to make the tty scrollable or even static . By static I mean that it should not scroll down and stay on the original screen even when new messages pop up. (So that I can see my printk's)
Press CTRL+s to freeze scrolling, and in fact any updating of the TTY.
Press CTRL+q to resume.
You can scroll with SHIFT+page up/page down
There is no way to stop it from scrolling at boot time (as far as I know).
You can use the command
sudo dmesg -n 1
to suppress all messages from the kernel (and its drivers) except panic messages from appearing on the console.
To fix at each boot, add the command to:
/etc/rc.local
I have been building an IT Ticketing / inventory system, and the program is done, now I'm adding instructions for the end users and the other techs in our school. Since I know nobody will read an instruction manual, I opted to make instructions for each screen, and put them in Modal Windows, activated by pushing a Help button I added to the Screen Commands section.
That works wonderfully, so I decided to capture the KeyDown event, and launch the window if they press F1. This is where things get a little weird.
If the HelpWindow for this particular screen has been opened at least once, pressing F1 opens it again with no trouble. If it has never been opened, pressing F1 results in an Error 'Control 'HelpWindow' doesn't contain a modal window. OpenModalWindow/CloseModalWindow cannot be used.'
After closing this error message, F1 will launch the HelpWindow exactly as expected. Very bizarre...
Background information:
Visual Studio 2012
Lightswitch project in VB (I work in both VB and C#, flipped a coin for this project)
The Modal Window is a group on the screen that is not visible, named "HelpWindow"; I use OpenModalWindow("HelpWindow") to open it. The exact same line of code in the HelpButton_Execute code, and the event handler for the KeyDown event.
It's the same method I use for every other modal window in the program, for submitting new tickets, adding equipment to the inventory, etc.
This problem only happens in the event handler, and only the first time the F1 key is pressed. The behavior is the same on every screen that has a help window.
My attempts to Google the problem were fruitless. Has anybody ever seen this behavior before?
That does sound very strange. I have to admit that I haven't seen anything like this myself with a modal window.
You don't mention where you're trapping the KeyDown key, so it's a bit hard to comment on that.
What I have seen sometimes, especially when doing something a little "different", is the error message not telling you the actual cause of the problem.
I would try wrapping the code with a dispatcher call, to make sure the call is being performed on the correct thread, as well as a try/catch to see if you can find the real cause of the error:
Private Sub YourClickHandler
Try
Me.Details.Dispatcher.BeginInvoke(
Sub()
OpenModalWindow("HelpWindow")
End Sub)
Catch ex As Exception
Me.ShowMessageBox(ex.Message)
End Try
End Sub
I hope that helps, or at least points you in the direction of a solution.
I have an SDL2 windowed window accessed via Derelict 3.
It is supposed to strobe black and white (not because I hate epileptics), and it does this successfully. However, after a certain period of time, Ubuntu 13.10 marks the window as 'unresponsive', grays it out, and dulls the strobe effect.
This is highly irritating and totally kills the effect required by the application for visual stimulation to retrieve SSVEP readings from my EEG headset.
How do I get my OS to realize that the window is doing exactly what it should be doing?
Code
As I have wrapped the SDL calls in my actual code, I'm going to provide pseudo-code and the SDL methods called in those sections (I've checked that I'm not calling any other SDL functions):
make a window using SDL_CreateWindow (no set flags)
make a renderer using SDL_CreateRenderer (with presentvsync flag set)
for( ... )
{
fill screen black using SDL_RenderFillRect and SDL_SetRenderDrawColor
update screen using SDL_RenderPresent
fill screen white (same as above filling)
update screen (same as above update)
}
exit
I pedantically check error codes and return values for all SDL calls in the wrapper lib. They're all fine. What I need to know is what I must add to provide the heartbeat to my OS so it stops graying out my window.
Another thing...
Could someone please add an SDL2 tag? SDL2 has a very different API from SDL1.2...
Added event processing into the loop via SDL_PollEvent(null). This satisfied the OS.
For anyone using Ubuntu 16.04 and SDL2.0x -
The solution that worked for me was:
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_PING,"0");
set immediately after your SDL_Init(); call.
see : SDL2 wiki here.
I'm trying to use the ocaml graphics module.
The line:
#Graphics.open_graph "";;
works fine in the interactive module, i.e. a small window pop up in X11 with white background.
However, when I try to use the script mode -- put this line in a file then compile it:
ocamlc -o a.out graphics.cma code.ml
only X11 starts but with no window popup.
Am using a mac. Anyone knows why? Thanks.
Followup:
It seems under script mode the popup window will closeup immediately after code execution. Because if I compile using XTerminal, I can see a small window popup but then closes.
I managed to keep the window open by adding an infinit loop at the bottom:
while true do () done;;
But still don't understand how things really work. Please help. Thanks.
All ressources are freed when the script terminates: memory, file descriptors, including the X window.
If you add an infinite loop, the script does not terminates, and the windows stays open.
Likewise, under the toplevel, the window stays open as long as you don't close the toplevel.
I would suggest to add two lines add the end of your script:
print "press enter to exit"
read one line from keyboard input
This way the script will not terminate until the user presses enter.
Indeed, as jrouquie explains you need to delay the termination of your program. The way I personally do that is by waiting on user input. At the end of the interactive program (or function being studied that opens the graphic mode), I put:
ignore (Graphics.read_key ())
This will wait until a key has been hit on the keyboard, and ignore the key value before returning.