My application adapts to a slow framerate in a few different ways. When I run a PIX experiment, rendering gets much slower so these techniques get activated. I would like to disable this without having to do a seperate build when I want to use PIX. Something like:
if (running_slow() && !running_pix()) {
reduce_graphics();
}
In the DirectX June 2010 SDK:
bool running_pix() {
return D3DPERF_GetStatus() != 0;
}
Related
I want to create a GUI toolkit for my desktop environment (because neither gtk nor qt don't fit to my needs) but I don't know how to start. I don't want a cross-platform or display-server independent library, theming options, configurable icons etc. just a few basic widgets for making wayland clients. (widgets like button, entry, label, window and images... and I want to use CSD if it's important)
My problem is that I can't understand how graphics work in wayland (in X you only need to create a window and use XDrawLine etc. right?) also I don't know how to write a graphical toolkit. Can you give me some articles or recommendations on how can I do this?
The easiest way to create a wayland client is to use the wayland-client library. Basically, it abstracts the wire format.
example:
#include <stdio.h>
#include <wayland-client.h>
int main(void)
{
struct wl_display *display = wl_display_connect(NULL);
if (display) {
printf("Connected!\n");
} else {
printf("Error connecting ;(\n");
return 1;
}
wl_display_disconnect(display);
return 0;
}
I want to add swipe gestures in my application based on Qt5. The application is intended to run primarily on Linux (laptop). I was just not able to write code because I couldn't understand how to use the class (no example code was available).
The touchpad driver supports swipe gestures (libinput). Also, synaptics (on my system at least) support multi-finger touch.
Can someone please guide me about how to use the API, and provide with some example code?
Do you mean QNativeGestureEvent? You probably shouldn't mess with QNativeGestureEvent and use the higher-level framework: see Gestures in Widgets and Graphics View. The QNativeGestureEvent used to be only available on OS X; it's not really an API that's meant for wide consumption.
Alas, the QNativeGestureEvents are delivered to the widgets themselves. You would react to them by reimplementing QObject::event and acting on the event:
class MyWidget : public QWidget {
typedef base_type = QWidget;
...
bool QWidget::event(QEvent * ev) override {
if (ev->type() == QEvent::NativeGesture) {
auto g = static_Cast<QNativeGestureEvent*>(ev);
...
return true; // if event was recognized and processed
}
return base_type::event(ev);
}
};
But don't do that.
I'm thinking of using CrashRpt open-source library but I'm worried about performance.
The app performance requirement is critical so it's very importing not to slow it down.
The author affirms that there's no performance degradation but I would like to hear some other people opinions.
I was checking the demos of this library and in the case of MFC app, you just need to load the DLL on the main project and override CWinApp::Run()
The way it does it is like this:
int CMFCDemoApp::Run()
{
// Install crash reporting...
BOOL bRun = TRUE;
BOOL bExit=FALSE;
while(!bExit)
{
bRun= CWinApp::Run();
bExit=TRUE;
}
// Uninstall crash reporting...
return bRun;
}
You can check all the demo code on this link:
https://sourceforge.net/p/crashrpt/code/ci/master/tree/demos/MFCDemo/MFCDemo.cpp
I have never overriden CWinApp::Run(), so I don't know if that while() loop will affect in some way.
Thanks in advance for your opinions.
So I'm writing a boid simulation program as a project for school. My program supports multiple different groups of these boids that don't flock with other groups, they all have different settings which I do by adding a BoxPanel to the main GUI of the program when a new tribe is made, and those BoxPanels have a settings button that opens a new frame with the groups settings.
This works perfectly when I start the program up and add all the pre defined tribes that are in the code. Now I made a new part of the GUI that let's you make new groups of these boids and adds them while the simulation is running, and here is when the problems start for me.
For some weird reason it adds the group just fine, with the right settings in to the simulation but it wont add the BoxPanels to the main GUI. It makes the whole settings bar that I have in the side of my simulation disappear completely. I tested this out and if I add the tribes in the beginning of my calculation thread it does the same thing, so this seems to be a problem with multiple threads and swing. Any ideas what is causing this or how to fix this? I am completely perplexed by this.
tl;dr: The code below for adding tribes works fine when I haven't started the thread but if I try to use it after starting the thread the optionPanel appears empty.
Here's the code that adds the BoxPanels to the main gui:
def addTribe(tribe: Tribe) = {
tribeFrames += new TribeSettingFrame(tribe)
tribeBoxPanels += new TribeBoxPanel(tribe)
this.refcontents
}
private def refcontents = {
top.optionPanel.contents.clear()
top.optionPanel.contents += new BoxPanel(Orientation.Vertical) {
tribeBoxPanels.foreach(contents += _.tribeBoxPanel)
}
top.optionPanel.contents += new BoxPanel(Orientation.Horizontal) {
contents += top.addTribeButton
}
top.optionPanel.contents += new BoxPanel(Orientation.Horizontal) {
contents += top.vectorDebugButton
}
}
new Thread(BoidSimulation).start()
Oh and I tested if it really adds the contents that it should by printing out the sizes of the contents, and everything matches fine, it just won't draw them.
EDIT: After some digging around it really seems to be a thing with updating swing from a Thread. A lot of places suggest to use SwingWorker but from the info I gathered about it I don't think it would fit in my program since it is a continuous simulation and and I would have to keep making new SwingWorkers every frame.
EDIT2: Tried calling the method from the thread like this:
SwingUtilities.invokeLater(new Runnable() {
override def run() {
GUI2D.addTribe(tribe)
}
});
Didn't make any difference. I am starting to think that this is a problem with how I use TribeBoxPanel and TribeSettingFrame. These are objects that both contain only one method that returns the wanted BoxPanel or Frame. Is this implementation bad? If so what is the better way of creating dynamic BoxPanels and Frames?
Swing is not thread-safe.
Repeat after me.
Swing is not thread-safe.
Hear the chorus? Swing is not thread safe There is official documentation.
There is a very simple workaround given as well.
SwingUtilities.invokeLater(new Runnable() {
#Override public void run() {
// your stuff
}
});
In Scala, this is supported as:
Swing.invokeLater(/* your stuff */)
First you should let the UI thread handle all UI manipulation.
The simple way should be following Scala-Code:
Swing.onEDT { GUI2D.addTribe(tribe) }
But as you already noted, this won't solve your problem. I had a very similar problem where I only changed the text content of a Swing.Label and it sometimes simply disappeared.
It turned out that it only disappeared, when the text was too long to display it inside the Area which the Label initially reserved for itself. So one way around your Problem could be to give the optionPanel a bigger initial size when you create it.
Swing.onEDT { top.optionPanel.preferredSize = new Dimension(width,height) }
I'm not quite sure whether this has to be set before the component is first drawn (before Frame.open() is called).
I'm writing a mobile phone game using j2me. In this game, I am using multiple Canvas objects.
For example, the game menu is a Canvas object, and the actual game is a Canvas object too.
I've noticed that, on some devices, when I switch from one Canvas to another, e.g from the main menu to the game, the screen momentarily "flickers". I'm using my own double buffered Canvas.
Is there anyway to avoid this?
I would say, that using multiple canvases is generally bad design. On some phones it will even crash. The best way would really be using one canvas with tracking state of the application. And then in paint method you would have
protected void paint(final Graphics g) {
if(menu) {
paintMenu(g);
} else if (game) {
paintGame(g);
}
}
There are better ways to handle application state with screen objects, that would make the design cleaner, but I think you got the idea :)
/JaanusSiim
Do you use double buffering? If the device itself does not support double buffering you should define a off screen buffer (Image) and paint to it first and then paint the end result to the real screen. Do this for each of your canvases. Here is an example:
public class MyScreen extends Canvas {
private Image osb;
private Graphics osg;
//...
public MyScreen()
{
// if device is not double buffered
// use image as a offscreen buffer
if (!isDoubleBuffered())
{
osb = Image.createImage(screenWidth, screenHeight);
osg = osb.getGraphics();
osg.setFont(defaultFont);
}
}
protected void paint(Graphics graphics)
{
if (!isDoubleBuffered())
{
// do your painting on off screen buffer first
renderWorld(osg);
// once done paint it at image on the real screen
graphics.drawImage(osb, 0, 0, Tools.GRAPHICS_TOP_LEFT);
}
else
{
osg = graphics;
renderWorld(graphics);
}
}
}
A possible fix is by synchronising the switch using Display.callSerially(). The flicker is probably caused by the app attempting to draw to the screen while the switch of the Canvas is still ongoing. callSerially() is supposed to wait for the repaint to finish before attempting to call run() again.
But all this is entirely dependent on the phone since many devices do not implement callSerially(), never mind follow the implementation listed in the official documentation. The only devices I've known to work correctly with callSerially() were Siemens phones.
Another possible attempt would be to put a Thread.sleep() of something huge like 1000 ms, making sure that you've called your setCurrent() method beforehand. This way, the device might manage to make the change before the displayable attempts to draw.
The most likely problem is that it is a device issue and the guaranteed fix to the flicker is simple - use one Canvas. Probably not what you wanted to hear though. :)
It might be a good idea to use GameCanvas class if you are writing a game. It is much better for such purpose and when used properly it should solve your problem.
Hypothetically, using 1 canvas with a sate machine code for your application is a good idea. However the only device I have to test applications on (MOTO v3) crashes at resources loading time just because there's too much code/to be loaded in 1 GameCanvas ( haven't tried with Canvas ). It's as painful as it is real and atm I haven't found a solution to the problem.
If you're lucky to have a good number of devices to test on, it is worth having both approaches implemented and pretty much make versions of your game for each device.