void myDisplay(void) //glutDIsplayFunc(mydisplay)
{
while(1)
{
glClear(GL_COLOR_BUFFER_BIT);
x=rand()%680;
y=rand()%680;
sx=(x-p)/100;
sy=(y-q)/100;
glColor3f(0.7+sx,0.1-sy,0.6);
for(g=0;g<120;g++)
{
p+=sx;
q+=sy;
glBegin(GL_POINTS);
glVertex2i(p,q);
glEnd();
glutSwapBuffers();
}
}
}
This code just chooses one arbitrary point on screen and do smooth translation.
I compiled this same code in visual C++ and on linux and I noticed that the translation (from one point to another) happens fast on windows while on linux it drags slow.
why this is so?
Your are using a movement vector which is totally independent of the fps. This means that it will run with a different speed on a different machine.From your description I guess that on your Linux machine, sync to vblank is enabled, limiting your framerate to the refresh rate of the display (typically 60Hz), while on the windows machine, it is disabled, running with a much higher frequency.
You should use a timer to control animations, and define your animation speeds in sapce-units per time-unit.
Furthermore, you should follow Andon M. Coleman's advice: The GLUT display callback is mean to draw a single frame. If you want an animation over many frames, use some variables to store your current state (for example, the current position and direction vector) and update them for each step. The way you currently implemented it, GLUT's event handling will by blocked for the whole duration of the animation. On windows, this might even trigger "the application is not responding" warning, when your animation takes too long.
Related
I've written a program in C that activates commands when the user flicks from the edges of the screen. For instance, flicking upward from the bottom edge brings up the keyboard. This portion of my code is working fine.
The issue I am having is that the very making of the flicking motion also interrupts applications, as one's fingers need to drag across some of the screen to activate the trigger. I don't want this action to affect apps that are on screen while the user flicks the screen edge.
I would like to add some C code that will temporarily mask touch events. I can handle the code that activates the masking properly (such as events which originate from the edges of the screen) and when to unmask.
I can handle all of the above with exception to the code that does the masking and unmask of the touch events. I am not asking for a full complete code but just a pointer in the right direction. I would like to know what library to use and the appropriate command which does the masking.
I'll not post the code as it is a couple hundred lines long and would surely lead to straying from the question; the code works fine, aside from the issue above.
I am on a Raspberry Pi 3b+ with Rasbian OS and an Official Raspberry Pi 7" touch screen. The main C libraries which I am using for the program are linux/input.h and X11/extensions/XTest.h.
I will supply any additional info if asked.
* EDIT *
Finally figured it out! The biggest issue what finding what to search for...
I masked the pointer/touch events with the following command:
XGrabPointer(dpy, root, False, PointerMotionMask, GrabModeSync, GrabModeAsync, None, None, CurrentTime);
In the code above, the touch motion is masked (PointerMotionMask), the pointer/touch for windows is masked (GrabModeSync), and the keyboard key events are not masked (GrabModeAsync).
To unmask, I used these commands:
XQueryPointer(dpy, RootWindow (dpy, 0),
&event.xbutton.root, &event.xbutton.window,
&event.xbutton.x_root, &event.xbutton.y_root,
&event.xbutton.x, &event.xbutton.y,
&event.xbutton.state);
usleep(10000);
XUngrabPointer(dpy, CurrentTime);
usleep(10000);
XQueryPointer(dpy, RootWindow (dpy, 0),
&event.xbutton.root, &event.xbutton.window,
&event.xbutton.x_root, &event.xbutton.y_root,
&event.xbutton.x, &event.xbutton.y,
&event.xbutton.state);
I'm still learning Xlib, so I don't entirely know why one needs to add usleep and XQueryPointer, but I found that it's needed or the program is unpredictable. I merely copied this type of code from my buttonPress() function. I couldn't find any complete, simple, and clear answer, so a lot of try/fail was required on this one.
Now, I am able to swipe from the edges on my Raspberry Pi touchscreen, and there is no interruption to the currently active window.
If anyone wants to see the code, just ask and I'll post it in full. And if anyone knows how this code works and why I need to add usleep and XQueryPointer, I'd like to hear.
Sources used:
X11: will XGrabPointer prevent other apps from any mouse event?
https://tronche.com/gui/x/xlib/input/pointer-grabbing.html
I'm sorry if his question has already been asked in some way.
I'm currently re-writing a vibration driver in a Linux kernel. The reason why I changed it was due to overly strong vibrations caused by gaining a specific velocity of the vibration motor. To work that around I've implemented a PWM like controller that simply stops the motor at a specific time before reaching it's max acceleration, finally it keeps repeating this action.
There is one big issue that is mainly noticeable when using the keyboard. If the vibrator gets toggled too often in a very short time, the timer tends to stack up times, causing lag and vibration delays. This flaw can be easily achieved when typing multiple keys at once.
To demonstrate you this event visually I created a small graph.
The red area indicates timer overlap. The overlap between vibration 1 and 2 causes a delay for the second vibration, moving it out of place.
My main idea to prevent this issue is to merge vibrations into one if the previous vibration hasn't finished yet. For instance vibration 2 would simply join vibration 1.
Another way would be to simply use a single vibration for stacked vibrations, for instance, vibration 2 could simply use the last remaining bit of vibration 1. Why would this work? Well because the vibration controller that I've implemented only applies to times under 100ms, meaning vibration time differences would not be noticeable if one was to spam to keystrokes at once, instead both keystrokes should form and share single vibration.
Finally to my question, how could I make a function check itself it it's being called again. Or at least add a time for the function to check if keystrokes are being spammed multiple times in a short period?
int foo ()
{
static foo_counter;
if(foo_counter)
{
// If function has been called again
}
return(0);
foo_counter++;
}
The ST terminal has a patch for scrolling back. I want to update said patch to enable mouse wheel up and down signals in additions to "PageUp" and "PageDown". I suspect that a small change in config.h is what is needed but I have no experience in terminal code thus my plea for help.
In the source code, in config.h these lines appear:
static Mousekey mshortcuts[] = {
/* button mask string */
{ Button4, XK_ANY_MOD, "\031" },
{ Button5, XK_ANY_MOD, "\005" },
};
So, clearly, we know what Button4/5 are. In addition, we have these:
static Shortcut shortcuts[] = {
/* mask keysym function argument */
[...]
{ ShiftMask, XK_Page_Up, kscrollup, {.i = -1} },
{ ShiftMask, XK_Page_Down, kscrolldown, {.i = -1} },
};
So, naively, I a assuming that adding another two raw (one for wheel up, one for wheel down) would do the trick. However, what?
Note: I know that suckless recommends using a terminal multiplexer such as tmux. I use that already. However, sometimes (rarely) I just want to use a terminal without tmux and this feature would be useful. Please do not comment/answer to use tmux, this is not what this question is about.
It is not that simple. This question occasionally arises when someone wants left/right scrolling for a mouse trackball.
On the left column of the tables is an X event. Those are limited to combinations of predefined symbols.
Button4 and Button5 are mentioned because those are conventionally used to pass the mouse wheel events. That has been the case for quite a while; there was a resource file used before modifying xterm in 1999 (patch #120) to make this a built-in feature.
The possible X events are laid out in C header files — X.h — and tables in the X source code; no wheel mouse events are provided for as such. For instance, there is a table in the X Toolkit library which lists all of the possibilities (for clients using X Toolkit such as xterm). xev uses the header-definitions.
If X were to support wheel mouse events in a different way, it would probably use new function calls for this purpose since the existing information may be packed into bit-fields in a way that precludes easy extensibility.
There is now a standalone program scroll that provides scrollback buffer for any terminal emulator. At the time of writing this answer, it is still in an experimental state, a lot of bugs are expected. In spite of that, it already handles scrollback better than the scrollback patches for st. E.g. resizing the terminal will wrap previous output instead of cut off and lose them.
To enable it, first of course download/clone the source code from suckless website and build it locally.
Then modify this line in config.def.h of st (you have to fetch the recent git commits to get support for scroll)
char *scroll = NULL;
to
char *scroll = "/path/to/scroll";
Now rebuild st, and run st. It will automatically use scroll to provide the scrollback buffer.
As stated in the manual, another way without modifying st's source code is to run st with the following command after you have installed both st and scroll:
/path/to/st -e /path/to/scroll /bin/sh
From the suckless site, there are some scroll back patches that allow scrolling using Shift+MouseWheel as well as full mouse scroll. The last patch might break other mkeys excluding scrolling functions.
I'm looking for a method to wait for the GPU to finish its work in DirectX9. Something equivalent to the glFinish command in OpenGL...
I already know that it's not something I should do, but I have to! I'm writing a threaded Graphics Engine integrated in WPF and I need to make sort of an off-screen rendering in order to give a valid surface to a D3DImage. The frames are very long to compute (more than 100ms) and the rendering of the WPF Image sometimes occurs while the frame is not fully computed by my Engine even if I lock everything the right way. I'm almost sure it's just a Finish issue but I didn't find out how to do that.
So far, I tried to launch a DX9 query like this :
using namespace SlimDX.Direct3D9;
public class GraphicsDevice: Device
{
...
public void Finish()
{
var query = new Query(this, QueryType.Event);
EndScene();
while (!query.CheckStatus(true)) ;
}
}
But it does not seem to work...
So, first question without talking about WPF, do you know how to wait for the GPU to finish what has been sent to the driver?
Thanks!
This was the solution.
I was not aware that it actually work!
I used an EventQuery to 'mark' my last call to the GPU.
Then I put some kind of infinite loop flushing the GPU instructions and waiting for the EventQuery to be finally fired by the GPU, using the GetData/CheckStatus methods.
I want to handle scroll with the mouse wheel using ncurses but I am having a problem similar to this issue :
http://lists.gnu.org/archive/html/bug-ncurses/2012-01/msg00011.html
Besides, mouse wheel-up event is only reported as mask 02000000
(BUTTON4_PRESSED) just one time, even if I scroll the wheel continuously.
I tried ncurses 5.7 to 5.9 on debian 5,6,7 and archlinux.
Every single ncurses lib had NCURSES_MOUSE_VERSION 1, tried recompiling with --enable-ext-mouse.
Scrolling down works perfectly, ncurses reports multiple REPORT_MOUSE_POSITION 0x8000000 per scroll and a single BUTTON2_PRESSED 0x128.
Scrolling up causes only a single report of BUTTON4_PRESSED 0x80000
MEVENT event;
mousemask(BUTTON1_CLICKED|BUTTON4_PRESSED|BUTTON2_PRESSED, NULL); // Tried with REPORT_MOUSE_POSITION also
while(run)
{
switch(in = getch())
{
case KEY_MOUSE:
if(getmouse(&event) == OK)
{
else if (event.bstate & BUTTON4_PRESSED)
line_up();
else if (event.bstate & BUTTON2_PRESSED || event.bstate == 0x8000000)
line_down();
}
break;
}
}
Add mouseinterval(0); somewhere outside of your main loop. (Perhaps right after keypad(stdscr, TRUE);)
This command causes there to be no delay with mouse events, so you won't be able to detect BUTTON1_CLICKED or BUTTON1_DOUBLE_CLICKED and similar things (though you can implement that yourself by keeping track of BUTTON1_PRESSED, BUTTON1_RELEASED, and the time between mouse events).
A small caveat though, when I tested this with C everything worked, except that getmouse returned ERR on scroll wheel down events. This could potentially still be useful though, as it was the only event which gave this result. When I tested the same code in Rust it worked perfectly though, so your mileage may vary.
ncurses5 does not support wheel mouse, except as an optional feature. That is because the layout of bits in mousemask_t chose in the mid-1990s left insufficient space for a fifth mouse-button. At the time, some other devices (for playing games) seemed more important; this was before X provided a protocol for wheel mice.
The "extended mouse" is an optional feature (since it would change the application binary interface), and has not been incorporated in ncurses5 packages, although it has been available for some time.
For reference, see the discussion of --enable-ext-mouse in the ncurses changelog, starting in 2005.
ncurses6 does support wheel mouse (see release notes). Perhaps that will be standard in Debian 9.