I have created a clock widget for Samsung Gear S.
It works fine. But I want to support the "always on" feature of the watch, like other pre installed clock widgets. They are showing their clocks in black and white style while idle.
How can I do this?
Related
I have a project with a lot of button bars and a lot of graphic interfaces, the problem I have is that with graphic cards and new high-resolution monitors, when scaling, for example, 150% is set in the screen configuration, the buttons appear with the image very small; the image inside is not re-scaled to 150% like the rest of the application.
There is a series of buttons to which I assign the image in this way:
CImageList ilTest;
ilTest.Create(IDB_IL_DOC, 32, 0, RGB(255, 0, 255));
m_picDoc.SetIcon (ilTest.ExtractIcon (0));
...
Can it be modified in some way so that the button image is scaled in the same proportion as the rest of the interface?
See this article: MFC applications now default to being DPI-aware.
To quote the introductory paragraph:
Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team,
mainly responsible for MFC. I wanted to make you aware of a subtle
but meaningful change that we have made regarding MFC applications in
Visual Studio 2010: all MFC applications are now marked as ‘DPI aware’
by default. This means that your application is expected to handle
various DPI (dots-per-inch) settings, not just the default (96 DPI),
because Windows will not automatically scale the user interface
elements of your application to match the selected DPI of the system.
It eventually links to this article: High DPI Desktop Application Development on Windows which goes into details with some examples.
I admit that I have not delved into addressing the DPI issues in my own projects. It is something I should do.
Tools like Fraps work with games based on OpenGL or DirectX but doesn't work with simple Windows 8 Metro style games like "Cut The Rope" or "Pirates Loves Daisies". Yes I know that "Cut The Rope" and "Pirates Loves Daisies" are using different technologies like JavaScript and HTML5 canvas but I'm really curious is it possible to build Fraps like tool for such games (some kind of canvas hack?). I would like to do 2 things:
1. Measure fps.
2. Capture screenshots.
I was reading articles about the whole Fraps concept and intercepting calls to DirectX but I'm not sure if its gonna work with Metro applications. Maybe I'm just wasting my time. I have 2 questions for you guys:
1. Do You think is it possible to build Fraps like tool that works with Metro style applications or games that are NOT using DirectX or OpenGL?
2. Does messing around with dxgi.dll (or other dll) could help somehow?
Thanks
Fraps is able to display the framerate because of hooks it has into DirectX. HTML apps do not provide access to this same information.
I've confirmed that the free program ScreenPresso (http://www.screenpresso.com/) can record Cut The Rope just fine.
Try Intel GPA (graphics performance analyzers)
http://software.intel.com/en-us/vcsource/tools/intel-gpa
Install it and then run the app.
There are a zillion options for graphs and stuff that I don't entirely understand (maybe it will be useful to you). If you want fps, just close the window; the program will continue running in the background.
There should be an icon in the lower right next to battery info and volume control. If you hover over it, it says your IP address. Right click on the icon for GPA and then select "Analyze Application" at the top.
A window will pop up with all the tile apps on the machine. Click on the app (don't double click) and click "run" in the bottom right.
The frame rate and resolution will be displayed in the upper left corner.
Tested and it works for Cut the Rope (I'm getting 58-60 fps). Hope this helps.
I created a widget that serves as some kind of popup window und hence should have a drop shadow all around to optically raise it from the background. I initialize the drop shadow effect in the constructor of my popup widget as follows:
dropshadow = new QGraphicsDropShadowEffect(this);
dropshadow->setBlurRadius(32);
dropshadow->setColor(QColor("#121212"));
dropshadow->setOffset(0,0);
setGraphicsEffect(dropshadow);
The application runs on an embedded system with an Intel Atom CPU, a custom Linux distribution, Qt v4.7.3 running with a qws server. When I disable the drop shadow, my cpu usage is less than 10% when the GUI is idle. Enabling the drop shadow raises the cpu usage to more than 80%. Profiling the app shows that most of the CPU time is spent within libQtGui.so.4.7.3.
Does anyone have an idea why the cpu usage explodes like this even though there is absolutely nothing going on in the GUI, not even mouse movement?
Edit: Changing the size of the popup changes the amount of cpu usage. Reducing the size to a quarter reduces the cpu usage to about a quarter. Very strange.
The problem was only partly with the drop shadow. It seems that repainting a drop shadow requires quite a lot of CPU time - which is OK if it is not redrawn too often. The problem was simple really. The widget that was behind this popup was redrawn four to five times per second and hence, the popup needed to be redrawn, too. This swallowed huge amounts of CPU time. The solution is equally simple: Avoid repaint events if nothing really changes on screen.
I've developed a Qt/QML application which I display with a translucent QDeclarativeView in a translucent frameless QMainWindow (see this). The application is fairly complex with a a few ListViews inside and some threads that poll a remote server for data and feed the views. The program runs flawlessly and at full speed without glitches on Windows 7. But when I compile and run it on Snow Leopard I've got the following problems;
GUI rendering is slow in general
When I scroll the ListView with the mouse wheel, the wheel actions affect the underlying window and my GUI flickers as if it can't render fast enough. Also often when I click something on my GUI, the mouse click just passes through my window onto the underlying window and brings it in front.
Mouse actions feel awkward. There is a significant delay.
These problems are present on both the Release and Debug builds with/without gdb attached.
The problems sound related to me but I'm confused. Why would an application running perfectly on Win7 perform badly on Snow Leopard ? Am I missing some specific configuration ?
I have an EeePC 900 running Ubuntu Intrepid Ibex. The touchpad has some simple multi-touch gestures built in - scrolling by dragging with two fingers instead of one for example.
How would I detect multi-touch events in an OpenGL/C application?
Is the touchpad on the EeePC 900 capable of handling rotational and scaling gestures?
The MPX example returns with Only found one master pointer. and the suggested xinput --create-master "ImPS/2 Logitech Wheel Mouse" isn't recognised by xinput. So is the multi-touch scrolling behaviour built-in at a lower level?
(On my Eee 1000)
xev reveals that the two-finger scroll gesture is being turned into clicks of buttons 4 and 5. The three-finger tap is just turned into button 3. I don't think the pad supports any other operations. So it looks like the pad hardware is just generating clicks as though it is a wheel mouse.
I don't own an EeePC, however you may want to check out the MPX API for accessing multiple pointers in X. If you're looking for general multitouch frameworks, there are a few on Google Code.