Downloads

How to Integrate Intel® Perceptual Computing SDK with Cocos2D-x [PDF 482KB]

Introduction

In this article, we will explain the project we worked on as part of the Intel® Perceptual Computing Challenge Brazil, where we managed to achieve 7th place. Our project was Badaboom, a rhythm game set in the Dinosaur Era where the player controls a caveman, named Obo, by hitting bongos at the right time. If you’re curious to see the game in action, check out our video of Badaboom:

​

To begin, you’ll need to understand a bit about Cocos2D-X, an open-source game engine that is widely used to create games for iPhone* and Android*. The good thing about Cocos2D-X is that it is cross-platform and thus is used to create apps for Windows* Phone, Windows 8, Win32*, Linux*, Mac*, and almost any platform you can think of. For more information, go to www.cocos2dx.org.

We will be using the C++ version of the SDK (Version 9302) as well as the Cocos2D-X v2.2 (specifically the Win32 build with Visual Studio* 2012). Following the default pattern of Cocos2D, we will create a wrapper that receives and processes the data from the Creative* Interactive Gesture Camera and interprets it as “touch” for our game.

Setting the environment

To start, you’ll need to create a simple Cocos2D project. We will not cover this subject as it is not the focus of our article. If you need more information, you can find it on the Cocos2D wiki (www.cocos2dx.org/wiki).

To keep it simple, execute the Python* script to create a new project in the “tools” folder of Cocos2d-x and open the Visual Studio project. Now we will add the Intel Perceptual Computing SDK to the project.

To handle the SDK’s input, we will create a singleton class named CameraManager. This class starts the camera, updates the cycle, and adds two images to the screen that represent the position of the hands on the game windows.

CameraManager is a singleton class that is derived from UtilPipeline and imports the “util_pipeline.h” file. Here, we need to reconfigure some of the Visual Studio project properties. Figure 1 shows how to add the additional include directories for the Intel Perceptual Computing SDK.

   $(PCSDK_DIR)/include
   $(PCSDK_DIR)/sample/common/include
   $(PCSDK_DIR)/sample/common/res

Figure 1. Additional include directories

You must also include the following paths to the additional library directories:

   $(PCSDK_DIR)/lib/$(PlatformName)
   $(PCSDK_DIR)/sample/common/lib/$(PlatformName)/$(PlatformToolset)

Figure 2. Additional Library Directories

Add the following dependencies in the input section:

   libpxc_d.lib
   libpxcutils_d.lib

Figure 3. Additional Dependencies

Now we are ready to work on our CameraManager!

Start Coding!

First we need to make the class a singleton. In other words, the class needs to be accessible from anywhere in the code with the same instance (singleton classes have only one instance). For this, you can use a method:

CameraManager* CameraManager::getInstance(void)
{
    if (!s_Instance)
    {
        s_Instance = new CameraManager();
    }

    return s_Instance;
}

After that, we’ll build a constructor, a method that starts the camera:

CameraManager::CameraManager(void)
{
	if (!this->IsImageFrame()){
		this->EnableGesture();

		if (!this->Init()){
			CCLOG("Init Failed");
		}
	}

	this->hand1sprite = NULL;
	this->hand2sprite = NULL;

	hasClickedHand1 = false;
	hasClickedHand2 = false;

	this->inputAreas = CCArray::createWithCapacity(50);
	this->inputAreas->retain();
}

Many of the commands initialize variables that handle sprites which symbolize the users’ hands and get input as they close their hands. The next step is processing the data that comes from the camera.

void CameraManager::processGestures(PXCGesture *gesture){
	
	PXCGesture::Gesture gestures[2]={0};

	gesture->QueryGestureData(0,PXCGesture::GeoNode::LABEL_BODY_HAND_PRIMARY,0,&gestures[0]);
	gesture->QueryGestureData(0,PXCGesture::GeoNode::LABEL_BODY_HAND_SECONDARY,0,&gestures[1]);

	
	CCEGLView* eglView = CCEGLView::sharedOpenGLView();
	switch (gestures[0].label)
	{
	case (PXCGesture::Gesture::LABEL_POSE_THUMB_DOWN):
		CCDirector::sharedDirector()->end();
		break;
	case (PXCGesture::Gesture::LABEL_NAV_SWIPE_LEFT):
		CCDirector::sharedDirector()->popScene();
		break;
	}
}

To be clear, it is in this method that you can also add switch cases to understand voice commands and to implement more gesture handlers. Following this, we must process this information and display it in the CCLayer (Cocos2D sprite layer).

bool CameraManager::Start(CCNode* parent){
	this->parent = parent;

	if (this->hand1sprite!=NULL
    &&  this->hand1sprite->getParent()!=NULL){
		this->hand1sprite->removeFromParentAndCleanup(true);
		this->hand2sprite->removeFromParentAndCleanup(true);
	}

	this->hand1sprite = CCSprite::create("/Images/hand.png");
	this->hand1sprite->setOpacity(150);
    //To make it out of screen
	this->hand1sprite->setPosition(ccp(-1000,-1000));
	this->hand1Pos = ccp(-1000,-1000);
	
	this->hand2sprite = CCSprite::create("/Images/hand.png");
	this->hand2sprite->setFlipX(true);
	this->hand2sprite->setOpacity(150);
	this->hand2sprite->setPosition(ccp(-1000,-1000));
	this->hand2Pos = ccp(-1000,-1000);

	parent->addChild(this->hand1sprite, 1000);
	parent->addChild(this->hand2sprite, 1000);
	
	this->inputAreas->removeAllObjects();
	return true;
}

This method should be called each time a new frame is placed on the screen (most of the time into the onEnter callback). It will automatically remove the hand sprites from the previous parent and add them to the new CCLayer.

Now that our hand sprites have been added to the CCLayer we are able to handle their position by calling the follow method on the update cycle of the CCLayer (which is scheduled by the call: “this->scheduleUpdate();”). The update method is as follows:

void CameraManager::update(float dt){

	if (!this->AcquireFrame(true)) return;

	PXCGesture *gesture=this->QueryGesture();
	
	this->processGestures(gesture);

	PXCGesture::GeoNode nodes[2][1]={0};
	
    gesture->> QueryNodeData(0,PXCGesture::GeoNode::LABEL_BODY_HAND_PRIMARY,1,nodes[0]);
	gesture-> QueryNodeData(0,PXCGesture::GeoNode::LABEL_BODY_HAND_SECONDARY,1,nodes[1]);

	CCSize _screenSize = CCDirector::sharedDirector()->getWinSize();

	
	if (nodes[0][0].openness<20 && !this->hand1Close){
		this->hand1sprite->removeFromParentAndCleanup(true);
		this->hand1sprite = CCSprite::create("/Images/hand_close.png");
		this->hand1sprite->setOpacity(150);
		this->parent->addChild(hand1sprite);
		this->hand1Close = true;
	} else if (nodes[0][0].openness>30 && this->hand1Close) {
		this->hand1sprite->removeFromParentAndCleanup(true);
		this->hand1sprite = CCSprite::create("/Images/hand.png");
		this->hand1sprite->setOpacity(150);
		this->parent->addChild(hand1sprite);
		this->hand1Close = false;
	}
	
	if (nodes[1][0].openness<20 && !this->hand2Close){
		this->hand2sprite->removeFromParentAndCleanup(true);
		this->hand2sprite = CCSprite::create("/Images/hand_close.png");
		this->hand2sprite->setFlipX(true);
		this->hand2sprite->setOpacity(150);
		this->parent->addChild(hand2sprite);
		this->hand2Close = true;
	} else if (nodes[1][0].openness>30 && this->hand2Close) {
		this->hand2sprite->removeFromParentAndCleanup(true);
		this->hand2sprite = CCSprite::create("/Images/hand.png");
		this->hand2sprite->setFlipX(true);
		this->hand2sprite->setOpacity(150);
		this->parent->addChild(hand2sprite);
		this->hand2Close = false;
	}

	this->hand1Pos = ccp(_screenSize.width*1.5-nodes[0][0].positionImage.x*(_screenSize.width*HAND_PRECISION/320) + 100,
						 _screenSize.height*1.5-nodes[0][0].positionImage.y*(_screenSize.height*HAND_PRECISION/240));
	this->hand2Pos = ccp(_screenSize.width*1.5-nodes[1][0].positionImage.x*(_screenSize.width*HAND_PRECISION/320) - 100,
						 _screenSize.height*1.5-nodes[1][0].positionImage.y*(_screenSize.height*HAND_PRECISION/240));

	if (!hand1sprite->getParent() || !hand2sprite->getParent()){
		return;
	}
	this->hand1sprite->setPosition(this->hand1Pos);
	this->hand2sprite->setPosition(this->hand2Pos);

	
    CCObject* it = NULL;
	CCARRAY_FOREACH(this->inputAreas, it)
	{
		InputAreaObject* area = dynamic_cast<InputAreaObject*>(it);
		this->checkActionArea(area->objPos, area->radius, area->sender, area->method);
	}
			
	this->ReleaseFrame();

}

This code not only handles the position of the sprite, it also sets a different sprite (hand_close.png) if the camera detects that the hand is less than 20% open. In addition to this, there is simple logic to create hand precision, which makes the user input more sensitive and easier to get the edges of the screen. We do this because the Perceptual Camera is not that precise on the edges, and the position of the sprites commonly get crazy when we approach the edge.

Now it is indispensable that we add some ways to handle the input (a closed hand is considered a touch). We need to write a method called “checkActionArea” (called in the update method) and register the actionArea.

void CameraManager::checkActionArea(CCPoint objPos, float radius, CCObject* sender, SEL_CallFuncO methodToCall){

	if (sender==NULL)
		sender = this->parent;

	float distanceTargetToHand = ccpDistance(this->hand1Pos, objPos);
	if (distanceTargetToHand<radius){
		if (this->hand1Close&& !hasClickedHand1){

			this->parent->runAction(CCCallFuncO::create(this->parent, methodToCall, sender));
			hasClickedHand1 = true;
		}
	}
	
	if (!this->hand1Close){
		hasClickedHand1 = false;
	} //TODO: repeat for hand2
}

Follow the method registerActionArea() for the registration of areas:

void CameraManager::registerActionArea(CCPoint objPos, float radius, cocos2d::SEL_CallFuncO methodToCall){

	InputAreaObject* newInputArea = new InputAreaObject(objPos, radius, methodToCall);
	this->inputAreas->addObject(newInputArea);
}

Now it is easy to add the Intel Perceptual Computing SDK to your Cocos2D game!!! Just run:

CameraManager::getInstance()->Start(this);

When entering the Layer, register the objects and methods to be called:

CameraManager::getInstance()->registerActionArea(btn_exit->getPosition(), 150, callfuncO_selector(LevelSelectionScene::backClicked));

About us!

Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.
Copyright © 2013 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.

By Lynn Thompson

Downloads

Implementing Multiple Touch Gestures Using Unity* 3D with TouchScript [PDF 1.48MB]

This article provides an overview and example for the several TouchScript gestures (Press, Release, Long Press, Tap, Flick, Pan, Rotate, and Scale) available when developing touch-based Unity* 3D simulations and applications running on Ultrabook™ devices with the Windows* 8 operating system. TouchScript is available at no cost from the Unity 3D Asset Store.

The example used in this article starts with a preconfigured scene imported from Autodesk 3ds Max*. I then add geometry to the Unity 3D scene to construct graphical user interface (GUI) widgets that accept touch input from the user. The multiple gestures available via TouchScript will be implemented and customized such that adjustments to the widget can be made during runtime, allowing for a GUI widget that can provide a touch UI that is acceptable to a wider audience when running a Unity 3D-based application on Window 8.

Creating the Example

I first import into Unity 3D an Autodesk 3ds Max FBX* export that contains a few geometry primitives and a small patch of banyan and palm trees (see Figure 1). I add a first-person controller to the scene; then, I assign a box collider to the box primitive imported from Autodesk 3ds Max, which acts as the scene’s floor, to prevent the first-person controller from falling out of the scene.

Figure 1. Unity* 3D editor with a scene imported from Autodesk 3ds Max*

Next, I add eight spheres (LeftLittleTouch, LeftRingTouch, LeftMiddleTouch, LeftIndexTouch, RightLittleTouch, RightRingTouch, RightMiddleTouch, and RightIndexTouch) as children of the main camera, which is a child of the first-person controller. I give these spheres a transform scale of x = 0.15 y = 0.30 z = 0.15 and position them in front of the main camera in a manner similar to fingertips on a flat surface. I add a point light above the modified spheres and make a child of the main camera to ensure illumination of the spheres. The layout of these modified spheres is shown in Figure 2.

Figure 2. Unity* 3D runtime with a first-person controller and modified spheres as children for the touch interface

This ends the base configuration of the example. From here, I add TouchScript gestures to the modified spheres and configure scripts to generate a desired touch response.

Adding Press and Release Gestures

The first-person controller from the initialization step of the example contains the JavaScript* file FPSInput Controller.js and the C# script Mouse Look.cs. The FPSInput Controller.js script takes input from the keyboard; Mouse Look.cs, obviously, takes input from the mouse. I modified these scripts to contain public variables that replace vertical and horizontal inputs into FPSInput Controller.js and to replace mouseX and mouseY inputs into the Mouse Look.cs script.

This replacement is fairly straightforward in FPSInputController.js because the keyboard sending a 1, −1, or 0 to the script is replaced with a touch event that results in public variables being changed to a 1, −1, or 0. The touch objects, their respective scripts, and the values they send to script FPSInputController are provided in Table 1 and can be viewed in their entirety in the Unity 3D FirstPerson project accompanying this article.

Table 1. Touch Objects and Corresponding Scripts in FPSInputController.js

This method works for controller position because the information is discrete, as are the TouchScript onPress and onRelease functions. For rotation, an angle variable needs to be updated every frame. To accomplish this, I send a Boolean value to a Mouse Look.cs public variable, and the rotation angle is changed in the Mouse Look.cs Update function at a rate of 1 degree per frame accordingly. The touch objects, their respective scripts, and the values they send to the Mouse Look.cs script are provided in Table 2 and can be viewed in their entirety in the Unity 3D FirstPerson project accompanying this article.

Table 2. Touch Objects and Corresponding Scripts in Mouse Look.cs

These scripts allow touch interface for first-person shooter (FPS) position and rotation control, replacing keyboard and mouse input.

Using the LongPress Gesture

My original intent for this example was to have the LongPress Gesture make all the touch objects disappear after at least one object had been pressed for a certain amount of time. The touch objects would then all reappear after all touch objects had instigated a release gesture and had not been touched for a certain amount of time. When I tried implementing it this way, however, the behavior was not as I expected, possibly because the LongPress Gesture was used in conjunction with the standard Press and Release Gestures. As a workaround, I implemented this functionality by using the already-implemented Press and Release Gestures in combination with public variables and the delta time method in the system timer.

When initially setting up the Unity 3D scene, I configured a TopLevelGameObject asset to hold the TouchScript Touch Manager and the TouchScript Windows 7 Touch Input script. To facilitate the desired LongPress Gesture, I added a custom C# script named PublicVariables.cs to the TopLevelGameObject asset. I did this not only to hold public variables but also to perform actions based on the state of these variables.

To configure this disappear and reappear functionality, I configured each move and look script associated with its respective touch sphere to have access to the public variables in PublicVariables.cs. PublicVariables.cs contains a Boolean variable for the state of each modified sphere’s move or look Press Gesture, being true when the modified sphere is pressed and false when it is released.

The PublicVariables.cs script uses the state of these variables to configure a single variable used to set the state of each modified sphere’s MeshRenderer. I configure the timer such that if any modified sphere or combination of modified spheres has been pressed for more than 10 seconds, the variable controlling the MeshRenderer state is set to False. If all of the spheres have been released for more than 2 seconds, the MeshRenderer state is set to True. Each move and look script has in its Update function a line of code to enable or disable its respective sphere’s MeshRenderer based on the state of this variable in PublicVariables.cs.

This code results in all of the modified spheres disappearing when any sphere or combination of spheres has been pressed for more than 10 consecutive seconds. The modified spheres then all reappear if all modified spheres have been released for more than 2 seconds. By enabling and disabling the modified spheres’ MeshRenderer, only the modified sphere’s visibility is affected, and it remains an asset in the scene and is able to process touch gestures. As such, the modified spheres are still used to manipulate the scene’s first-person controller. The user is required to intuitively know where the spheres are positioned and be able to use them while they are not being rendered to the screen. Examine the PublicVariables, Move, and Look scripts in the example provided to see the code in its entirety.

The Tap Gesture

To demonstrate the use of multiple gestures with one asset, I add the Tap Gesture to all four move spheres. The Tap Gesture is configured in all four of the left GUI widget’s modified spheres’ respective move scripts. The move scripts are then configured for access to the first-person controller’s Character Motor script. I configure the tap functions in each move script to manipulate the maximum speed variables in the Character Motor’s movement function.

The MoveForward script attached to the LeftRingTouch modified sphere is configured so that a Tap Gesture increases the maximum forward speed and maximum reverse speed by one. I configure the MoveReverse script attached to the LeftIndexTouch modified sphere for a Tap Gesture to decrease the maximum forward speed and maximum reverse speed by one. I configure the MoveLeft script attached to the LeftLittleTouch modified sphere for a Tap Gesture to increase the maximum sideways speed by one and the MoveRight script attached to the LeftMiddleTouch modified sphere for a Tap gesture to decrease the maximum sideways speed by one. The maximum speed variables are floating-point values and can be adjusted as desired.

When using the default settings with the Tap Gesture, the speeds change during the period when the user may want to press the modified sphere to instigate movement. In short, Press and Release Gestures are also considered Tap Gestures. To mitigate this behavior, I changed the Time Limit setting in the Will Recognize section of the Tap Gesture (see Figure 3) from Infinity to 0.25. The lower this setting, the sharper the tap action must be to instigate the Tap Gesture.

Figure 3. Unity* 3D editor showing a modified Time Limit setting in a Tap Gesture

The modified sphere can be used to navigate the scene and adjust the speed at which the scene is navigated. A quirk of this method for navigating and adjusting speed is that when a Tap Gesture is used to adjust speed, the first-person controller is also moved in the direction associated with the modified sphere that was tapped. For example, tapping the LeftIndexTouch modified sphere to decrement the maximum forward speed and maximum reverse speed slightly moves the first-person controller, and subsequently the scene’s main camera, in reverse. In the accompanying Unity 3D project, I add GUI labels to display the maximum speed setting so that the labels can be visualized when tapping the modified spheres. You can remove this quirk by adding a GUI widget component that, when used, disables the Press and Release Gestures, allowing the user to tap the GUI widget component without moving the main scene’s camera. After the maximum forward speed and maximum reverse speed are set to the user’s preference, the new GUI widget component can be used again to enable the Press and Release Gestures.

When developing this portion of the example, I intended to add a Flick Gesture in combination with the Tap Gesture. The Tap Gesture was going to increase speed, and the Flick Gesture was intended to decrease speed. However, when adding both the Flick and the Tap Gestures, only the Tap Gesture was recognized. Both worked independently with the Press and Release Gestures, but the Flick Gesture was never recognized when used in conjunction with the Tap Gesture.

The Flick Gesture

To demonstrate the Flick Gesture, I add functionality to the modified spheres on the right side of the screen. The look scripts are attached to these spheres and control the rotation of the scene’s main camera, which is a child of the first-person controller. I begin by adding a Flick Gesture to each sphere. I configure the Flick Gestures added to the RightTouchIndex and RightTouchRing modified spheres that control horizontal rotation with their touch direction as horizontal (see Figure 4). I configure the Flick Gestures added to the RightTouchMiddle and RightTouchLittle modified spheres that control vertical rotation with their touch direction as vertical. This may be useful when the modified spheres have disappeared after being pressed for 10 or more seconds and the touch interface does not respond to the user’s flick (as opposed to responding in an undesired manner). The user then knows that the touch interface–modified spheres need to be released, allows 2 seconds for the modified spheres to reappear, and then reengages the touch GUI widget.

Figure 4. Unity* 3D editor showing a modified Direction setting in a Flick Gesture

Each look script uses the public variables that exist in the Mouse Look script. When a modified sphere is flicked, the Mouse Look script instigates a rotation in the respective direction, but because there is no flick Release Gesture, the rotation continues indefinitely. To stop the rotation, the user must sharply press and release the modified sphere that was flicked. This action causes an additional degree of rotation from the Press Gesture but is followed by the Release Gesture, which sets the respective rotation public variable to False, stopping the rotation.

Like the Tap Gesture, the Flick Gesture now works in conjunction with the Press and Release Gestures. Users can still rotate the scene’s main camera by holding down the appropriate modified sphere, releasing it to stop the rotation. With the Flick Gesture implemented, users can also flick the desired modified sphere to instigate a continuous rotation that they can stop by pressing and releasing the same modified sphere.

The Remaining Gestures

To this point in the example, all of the gestures implemented enhance the user’s ability to directly navigate the scene. I use the remaining gestures (Rotate, Scale, and Pan) to allow the user to modify the touch targets’ (the modified spheres) layout for improved ergonomics.

Also, up to this point, all of the gestures are discrete in nature. An immediate action occurs when a Unity 3D asset is tapped, pressed, released, or flicked. This action may be the setting of a variable that results in a continuous action (the flick-instigated rotation), but the actions are discrete in nature. The Rotate, Scale, and Pan Gestures are continuous in nature. These gestures implement a delta method where the difference between the current state of the gesture and that of the previous frame is used in the script to manipulate a Unity 3D screen asset as desired.

The Rotate Gesture

I add the Rotate Gesture in the same way as previous gestures. I use the Add Component menu in the Inspector Panel to add the TouchScript gesture, and the script attached to the touch asset receiving the gesture is modified to react to the gesture. When implemented, the Rotate Gesture is instigated by a movement similar to using two fingers to rotate a coin on a flat surface. This action must occur within an area circumscribed by the Unity 3D asset receiving the gesture.

In this example, rotating the modified spheres results in the capsule shape becoming more of a sphere as the end of the modified sphere is brought into view. This behavior gives the user an alternate touch target interface, if desired. In this example, this functionality is of more use for the modified spheres on the right side of the screen. For the rotate widget on the right side of the screen, the user can flick the appropriate modified sphere for constant rotation up, down, left, or right. I configure the modified spheres controlling vertical rotation with vertical flicks. I configure the modified spheres controlling horizontal rotation with horizontal flicks. The modified spheres controlling horizontal rotation can now be rotated so that the longest dimension is horizontal, allowing for a more intuitive flicking action.

When rotating the modified spheres that are closest to the center of the screen, the modified spheres take on a more spherical appearance. The farther away from the center screen the modified sphere is when being rotated, the modified sphere takes on a more capsule-like appearance. This is an effect of the modified sphere’s distance from the scene’s main camera. It may be possible to mitigate this affect by adjusting the axes on which the modified sphere rotates. The following line of code does the work of rotating the modified sphere when the Rotate Gesture is active:

targetRot = Quaternion.AngleAxis(gesture.LocalDeltaRotation, gesture.WorldTransformPlane.normal) * targetRot;

The second argument in the Quaternion.AngleAxis is the axis on which the modified sphere rotates. This argument is a Vector3 and can be changed as follows:

targetRot = Quaternion.AngleAxis(gesture.LocalDeltaRotation, new Vector3(1, 0, 0)) * targetRot;

By adjusting this Vector3 as a function of the modified sphere’s distance from the position relative to the scene’s main camera, I can remove the effect, resulting in the modified sphere’s appearance being more consistent and spherical across all the spheres.

The Scale Gesture

I add the Scale Gesture as an additional means of altering the modified sphere’s presentation. When rotated, the resulting circular touch target may not be large enough for the user’s preference. The user can employ the Scale Gesture to modify the size of the touch target.

The motion used to instigate a Scale Gesture is similar to the Pinch Gesture used on mobile devices. Two fingers are moved apart and brought together for a scale-down gesture. The fingers are together and moved apart to instigate a scale-up gesture. The code in the accompanying Unity 3D project scales the target asset uniformly. This is not required: You can code for scaling on any combination of the x, y, or z axes.

An additional feature that may help with user utilization of the GUI widgets is automatic scaling following the 10 seconds of constant use, resulting in the disappearance of the GUI widgets. By automatically multiplying a modified sphere’s transform.localscale by 1.1 whenever the modified sphere’s MeshRenderer has been disabled, the user automatically gets a larger touch target, which may reduce the user’s need to intermittently release the GUI widgets to confirm the modified sphere’s location on the touch screen.

The Pan Gesture

For the purposes of ergonomics, the Pan Gesture is probably the most useful gesture. It allows users to touch the objects to be manipulated and drag them anywhere on the screen. As the modified spheres are initially positioned, users may, depending on the Ultrabook device they are using, have wrists or forearms resting on the keyboard. With the Pan Gesture functionality implemented, users can drag the modified spheres to the sides of the screen, where there may be less chance of inadvertently touching the keyboard. For additional ergonomic optimization, users can touch all four modified spheres that affect the first-person controller and drag them at the same time to a place on the screen that allows them to rest their wrists and arms as desired.

The following two lines of code, taken from a Unity 3D example, do the work of moving the Unity 3D scene asset when the Pan Gesture is active:

var local = new Vector3(transform.InverseTransformDirection(target.WorldDeltaPosition).x, transform.InverseTransformDirection(target.WorldDeltaPosition).y, 0);
targetPan += transform.parent.InverseTransformDirection(transform.TransformDirection(local));

Note that in the above code, the z component of the Vector3 is zero and that in the accompanying example, when the modified spheres are moved, or panned, they move only in the x–y plane. By modifying this Vector3, you can customize the interface a great deal. The first example that comes to mind is having a Pan Gesture result in a much faster Unity 3D asset motion on one axis than another.

In the “Everything” example provided with TouchScript, the following line of code limits the panning of the manipulated asset on the y-axis:

if(transform.InverseTransformDirection(transform.parent.TransformDirection(targetPan - startPan)).y < 0) targetPan = startPan;

This line was commented out in the accompanying example but can easily be modified and implemented if you want to limit how far a user can move a GUI widget component from its original position.

Video 1: Touch Script Multi Gesture Example

Resolving Issues During Development of the Example

One issue I found during development was that the Rotate Gesture never seemed to be recognized when the Press, Release, and Tap Gestures were added. To work around this issue, I added a modified sphere to the GUI widget on the left side of the screen intended for use by the left thumb. I configured this modified sphere with a script (ToggleReorganize.cs) so that when a user taps the modified sphere, a Boolean variable is toggled in the PublicVariables script. All of the modified sphere’s scripts reference this variable and disable their Press, Release, Tap, or Flick Gesture when the toggle variable is True, resulting in a UI that requires the user to tap the left thumb button to modify the widget. The user must then tap this left thumb button again when finished modifying the widget to go back to navigating the scene.

During the process of implementing this functionality, I discovered that the right widget did not require this functionality for the widget to be modified. The user could rotate, pan, and scale the widget without tapping the left thumb modified sphere. I implemented the functionality anyway, forcing the user to tap the left thumb modified sphere in the left widget to alter the ergonomics of the right widget. I did this because the right widget became awkward to use when it was modified at the same time it was being used to navigate the scene.

Looking Ahead

In addition to the Unity 3D scene navigation control, users can customize the GUI widgets. They can rotate, scale, and move (pan) the components of the widget to suit their ergonomic needs. This functionality is valuable when developing applications that support multiple platforms, such as Ultrabook devices, touch laptops, and tablets. These platforms can be used in any number of environments, with users in a variety of physical positions. The more flexibility the user has to adjust GUI widget configuration in these environments, the more pleasant the user’s experience will be.

The GUI widgets used in the accompanying example can and should be expanded to use additional GUI widget components designed for thumb use that can control assets in the game or simulation or control assets that are components of the GUI widgets. This expansion may include items in the simulation, such as weapons selection, weapons firing, camera zoom, light color, and jumping. To alter the GUI widget components, these thumb buttons can change the modified spheres to cubes or custom geometry. They can also be used to change the opacity of a material or color that GUI widget components use.

Conclusion

This article and the accompanying example show that using TouchScript with Unity 3D is a valid means of implementing a user-configurable GUI widget on Ultrabook devices running Windows 8. The GUI widgets implemented in the example provide a touch interface for the Unity 3D first-person controller. This interface can similarly be connected to the Unity 3D third-person controller or custom controllers simulating an overhead, driving, or flying environment.

When developing Unity 3D GUI widgets for Ultrabook devices running Windows 8, the desired result is for users to not revert back to the keyboard and mouse. All of the functionality that is typically associated with a legacy UI (a keyboard and mouse first-person controller) should be implemented in a production-grade touch interface. By taking this into consideration when implementing the TouchScript gestures described in this article and the accompanying example, you can greatly increase your prospects for obtaining a positive user response.

Note: The example provided with this article uses and references the examples provided with TouchScript as downloaded at no cost from the Unity 3D Asset Store.

About the Author

Lynn Thompson is an IT professional with more than 20 years of experience in business and industrial computing environments. His earliest experience is using CAD to modify and create control system drawings during a control system upgrade at a power utility. During this time, Lynn received his B.S. degree in Electrical Engineering from the University of Nebraska, Lincoln. He went on to work as a systems administrator at an IT integrator during the dot com boom. This work focused primarily on operating system, database, and application administration on a wide variety of platforms. After the dot com bust, he worked on a range of projects as an IT consultant for companies in the garment, oil and gas, and defense industries. Now, Lynn has come full circle and works as an engineer at a power utility. He has since earned a Masters of Engineering degree with a concentration in Engineering Management, also from the University of Nebraska, Lincoln.

Intel, the Intel logo, and Ultrabook are trademarks of Intel Corporation in the U.S. and/or other countries.
Copyright © 2013 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.

This tutorial will help to setup your floating license environment very quickly.
Follow these steps and choose the setup scenario that matches best:

• Obtain your license file
• Set up the license manager
• Set up clients

Obtain your License File

Please refer to the note 'Who is eligible to obtain a license file?' below.
You need a MAC address of the license server (optional the license server name) to register and create your license file.

1. Obtain a MAC address of the license server.
   If you have the license manager tools already installed you can run:
       lmutil lmhostid
   and take any of the addresses issued. 
   Otherwise run:
   OS X*, Linux*:
       ifconfig
       and take any of the 'HWaddr' values displayed
   Windows*:
       ipconfig /all
   and take any of the 'Physical Address' values displayed
   Note:
   Remove all special characters from the string and - if required - fill up with leading zeros to get your 12-digits alphanumeric string which is your Host ID.

2. Obtain the license server name (optional)
   Specifying the real server name is optional at the registration step. You can enter a placeholder during registration and modify the server name in the license file later with a plain text editor.
   Linux / OS X:
        hostname
   Windows:
        echo %COMPUTERNAME%
    
3. Register your Serial Number
   Login to the Intel® Registration Center and enter your SN and email, or if you are already logged in, your SN at the bottom of the "My Products" page.
   Enter your Host ID and server name you obtained in Step 1.
   The license file will be emailed to the email address associated with your license registration.
   
   Note:
   Registration of the Intel® Cluster Studio XE for Linux* is a two-steps process. During registration you need to accept the product EULA. If you missed to accept the EULA you will not get a license file attached to the registration notification email from Intel. In that case visit IRC and register this serial number again where you will have the chance to accept the EULA.

Who is eligible to obtain a license file?

Only the license owner or license administrator can perform a license registration and obtain a license file. Registered users have the right to download products and have read-access to the license history only.

    How can I identify which role I have?

1. Login to the Intel Registration Center
2. Click on the related product on the left hand column "Product Subscription Information", for example:     
3. On the 'Subscription History' page click on 'Manage', for example:
       
4. If you have access to the 'Manage' too you are either the owner or license administrator. Registered users don't have access to the 'Manage' tool.
5. If you have access you will see the Manage Page where you can see who the license owner and the license administrator are, for example:
       
    

Set up the License Manager

You can use an existing FlexNet or FlexNet Publisher license manager (lmgrd) if its version is the same or higher as the version of the Intel vendor daemon (INTEL). The description in this section applies also to a redundant servers installation where all steps need to be done on all 3 license servers.
A single license server or a redundant license server configuration can manage licenses from clients running on different operating systems.
Please refer also to the Floating Licenses and Software License Manager Compatibility section.
Please set up your license manager according to one of the following scenarios that match best:

I have to install a new license manager on a license server

1. Download
   Go to the License Manager Download Page (if you are logged out from IRC, the login prompt appears first)
   Select the right platform from the drop-down menu and download the right version:
   _ia32: is for 32-bit operating systems
   _intel64 is for Intel® 64 operating systems
   The Intel® Software License Manager User's Guide is also available from this download page.
   Notes:
   - On the license manager download page there is the most current version available only.
   - Access problems to this site indicate that you don't have a valid floating license registration associated to your email.
   - Only license owners and license administrators have access to that site

2. Installation
   Linux* / OS X*:
   - Copy the downloaded file into the directory you want to install the license server.
   - Extract the downloaded file, for example:
          tar xzvf l_isl_server_p_2.2.005_intel64.tar.gz  (Linux)
          tar xzvf m_isl_server_p_2.2.005.tar.gz  (OS X)
   - Change to directory flexlm and run the installer, for example:
         cd flexlm 
         Install_INTEL
   Windows:
   - Run the self-extracting w_isl_server_p_2.xxx.exe file and follow the instructions provided with the graphical installation wizard.
    
3. Start the license manager
   Linux* / OS X*:
   From the license manager directory /flexlm start the license manager lmgrd. You can specify a single license file or a license directory (if you more license files). By default, the license file name is server.lic which was created by the license manager installation. However you can move any valid floating license into the /flexlm directory and start it with the license manager. Creating a log file with option -l is optional.
        lmgrd -c server.lic -l flexnet_logfile.txt (reads server.lic license file and creates logfile)
        lmgrd -c . -l flexnet_logfile.txt               (reads al .lic files from the flexlm directory and creates logfile)
   Windows:
   You can run the license manager under Windows as system service (recommended) or as user application in a command shell (sometimes required for some Windows OS versions).
   System service:
   - Start > Intel(R) Software Development Products > Intel(R) Software License Manager and browse to the license file.
   User application:
   - Open a command shell
   - Navigate to c:\Program Files (x86)\Common Files\Intel\LicenseServer\
   - lmgrd -c server.lic -l flexnet_logfile.txt      (reads server.lic license file and creates logfile)

I need to add another Intel software license to an existing installation.
You can combine licenses into one single license file (.lic) or copy all license files into a license directory
   
     Combine licenses

1. Make sure that the SERVER and VENDOR lines are identical
2. Remove the SERVER and VENDOR lines of your new license file
3. Copy rest of contents of new license into the existing license file
4. Have the license manager re-read the combined license file, for example
        lmgrd lmreread –c <combined_license_file>
   On Windows you can re-read the new license also via the license manager GUI (Start > Intel(R) Software Development Products)

     Create license directory

1. Create a new license directory (recommended: Use the flexlm installation directory)
2. Copy all existing and new license files there (no need to edit and combine license files)
3. Have the license manager re-read the combined license file
        lmgrd lmreread –c <license_dir>
   On Windows you can re-read the new license also via the license manager GUI (Start > Intel(R) Software Development Products)

I need to add an Intel software license to an existing FlexNet/FlexNet Publisher license manager (lmgrd) already running for 3^rd party SW.
Same as above, but you need to make sure that the license manager lmgrd is of same or higher version as the Intel Vendor Daemon INTEL/INTEL.exe.

     Check for compatibility

1. Download and install the Intel license manager as described above
2. Run the Intel Vendor Daemon as follows:
        INTEL -v
3. Run the license manager as follows:
        lmgrd -v
   If the major and minor versions of lmgrd is the are the same or higher than the INTEL vendor daemon's versions you can use the existing license manager with the Intel Vendor Daemon. Otherwise you need to install an Intel License Manager in parallel to the existing license manager and run it on a different port.

     Add Intel Vendor Daemon to an existing license manager

1. Download the Intel license manager package as described above.
2. Extract downloaded package on a temp dir:
   Note: Under Windows you cannot change the installation directory. So in order to not overwrite an existing license manager installation, install it on another PC!
3. Take the Intel Vendor Daemon file INTEL / INTEL.exe and copy it to a directory on the license server (recommended: Use existing directory where the license manager lmgrd / lmgrd.exe) is running.
4. If required (i.e. if you copy the Intel vendor daemon not into the default directory) edit the license file and specify a path where the vendor daemon is located, for example
        VENDOR /flexlm/INTEL
   or
        VENDOR c:\Program Files (x86)\Common Files\Intel\LicenseServer\INTEL.exe
5. Combine licenses or create a new license directory as described above.
6. Restart the license manager as described above.

Setup Clients

There are several ways to setup a floating licensed product on client machine, but the most appropriate ones for an existing product installation or new / update installation on clients are the following.
Please note that this chapter applies to a single-license-server configuration only. Please refer to the Tips & Tricks section to use this method also for a redundant server configuration.

Product already exists on client
In this case you only need to create a new license file:

1. Use an editor and create a file with extension .lic with the following contents:
   SERVER <server_name|IP-address> <ANY|<server_MAC_address> <port>
   USE_SERVER
2. Copy the file to the default license directory:
   Linux:
   /opt/intel/licenses (for a (sudo)root installation)
   $HOME/intel/licenses (for a user installation)
   OS X:
   /Users/Shared/Library/Application Support/Intel/Licenses
   Windows:
   c:\Program Files (x86)\Common Files\Intel\Licenses\ (on 64-bit Windows systems)
   c:\Program Files\Common Files\Intel\Licenses\ (on 32-bit Windows systems)
3. Remove (or rename) all old or unused .lic files in the license directory

Update installation on client

1. Start the product installer

2. When it comes to product activation, the default activation option will be "Use Existing Activation"
   Select that option only if you are sure that the right server license was already set up with a previous installation. Otherwise select the following:
   Use "Alternative Activation > Use License Server" and specify the server name and port of the license server.

New product installation on client
 

1. Start the product installer
2. When it comes to product activation, the default activation option will be "Use Serial Number"
3. Do not use this option, but select "Alternative Activation > Use License Server" instead and specify the server name and port of the license server.
   CAVEAT! In complex environments this step may take long time (several minutes) until client-server connection and license verification/installation is finished.

Troubleshooting, Tips & Tricks
 

How to best setup a redundant server configuration

Setup of a redundant license server configuration remotely as described above is not supported by default, but you can perform the same steps as described above by referencing one of the servers only. After installation and server set up you can "expand" your client license by adding the other 2 servers in the client license, such as:

     SERVER <servername1> ANY <port>
     SERVER <servername2> ANY <port>
     SERVER <servername3> ANY <port>
     USE_SERVER

How to check license configuration from client

You can use the lmutil tool also on the client to perform the same license server checks as on the server.
Copy over the lmutil tool from the license server to the client or obtain it from FLEXERA's webpage (http://www.globes.com/support/fnp_utilities_download.htm).
Instead of using the license file or license directory use port@server as license parameter to invoke lmutil on the client, for example:
     lmutil lmstat -a -c <port>@<servername>
     lmutil lmdiag -c <port>@<servername>

How to check which license is being used

Linux only:
On Linux a very comfortable method is available to check which license and license server are being used. Create the enviornment variable FLEXLM_DIAGNOSTICS, assign it value 3 and invoke any of the tools icc, ifort, amplxe-cl, inpxe-cl or idbc, for example:

Linux/OS X:
Create the INTEL_LM_DEBUG enviornment variable, assing it a log file name and  invoke any of the tools icc, ifort, amplxe-cl, inpxe-cl or idbc. Search the logfile for any occurrence of the string SMSAxxxxxxxx. This 8-characters suffix is the serial number of the product that was used by invoking the product.For example:

Windows:
Open an Intel Software Development Product command prompt from the Start menu, create the INTEL_LM_DEBUG enviornment variable, assing it a log file name and  invoke any of the tools icl, ifort, amplxe-cl or inpxe-cl. Search the logfile for any occurrence of the string SMSAxxxxxxxx. This 8-characters suffix is the serial number of the product that was used by invoking the product.For example: 
      
       

Mixed Windows/Linux/OS X license server/client environment

You can run a single license server to manage a combined license for different client operating systems. The license server can run on Windows, Linux or OS X. In a heterogeneous environment it may be required to specify the full license server name including the full primary DNS suffix or the IP address in the license files of the clients.

Floating Licenses and Software License Manager Compatibility

In order to have full functionality of floating licensing service it is strongly recommended to use a license manager version that is specified for use with your product (please refer to the 'System Requirements' in the product release notes). Incompatible Intel license manager versions may result in reduced functionality when updating products on your client machines; for example they may not detect existing product activations or allow product activation via license server.

If you encounter problems updating products try one of the following workarounds:

• Upgrade Intel® Software License Manager to the newest version available on the Intel® Registration Center (choose the right OS and platform; only users with floating license registrations have access to this link).
• Use serial number (alphanumeric code of format xxxx-xxxxxxxx)
• Use license file (file extension .lic).

Note: Remote activation is not supported for floating licenses.

Disclaimer and Legal Information

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.
Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.
The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or by visiting Intel's Web Site.
Intel processor numbers are not a measure of performance. Processor numbers differentiate features within each processor family, not across different processor families. See http://www.intel.com/products/processor_number for details.
Intel, Intel Atom, and Intel Core are trademarks of Intel Corporation in the U.S. and/or other countries.

* Other names and brands may be claimed as the property of others.
Java is a registered trademark of Oracle and/or its affiliates.
Copyright © 2013, Intel Corporation. All rights reserved.

Introduction

The purpose of this article is to show how we can easily integrate VTune™ Amplifier into Eclipse* by using the External tool configuration capability in Eclipse.  We will create several Eclipse external tool configurations for both launching collections and displaying collected data.

Overview

These are are the tool configurations we will be creating:

1. Local collection running for a duration of 5 seconds with results stored in Eclipse project.
2. Displaying collected results in the VTune Amplifier GUI.
3. Local collection launching an application created in an Eclipse project
4. Remote collection running on an embedded target for 5 seconds.

Details

External tool configuration #1 - Local collection running for a duration of 5 seconds with results stored in Eclipse project

Select Eclipse menu item Run->External Tools->External Tools Configurations…

This will bring up the External tool configuration dialog.

In our first configuration will be running a local advanced-hotspot collection for a duration of 5 seconds.

Click on the “New Item” icon.

• Name = amplxe-local
• Location is the local of the amplxe-cl executable in your file system. (/opt/intel/vtune_amplifier_xe_2013/bin64/amplxe-cl
• Arguments= -collect advanced-hotspot –r ${project_loc}/vtune_result@@@{at} –d 5

Once you have specified these values you can click apply to save. Then you can kick off a data collection by clicking Run.

Now that you have created a configuration you can kick off a run by using the menu item: Run->External Tools->amplxe-local.

This run will create a VTune Amplifier result directory in your project directory. 

External tool configuration #2 - Displaying collected results in the VTune Amplifier GUI

We can create a new External tool configuration to open this result using the VTune™ Amplifier GUI.

Select Eclipse menu item Run->External Tools->External Tools Configurations…

This will bring up the External tool configuration dialog.

Click on the “New Item” icon.

• Name = amplxe-gui-project
• Location is the file path of the amplxe-cl executable in your file system. (/opt/intel/vtune_amplifier_xe_2013/bin64/amplxe-gui
• Arguments=${resource_loc}

Click Apply, Then Click on the VTune Amplifier result directory in your project, the click Run. This will launch the VTune Amplifier GUI on the result directory you have selected.

External tool configuration #3 - Local collection launching an application created in a Eclipse project

For our next configuration we will reference an application that we built as part of the Eclipse/CDT. We will call this configuration amplxe-local1, in this case all of values will be the same as the configuration except we will not specify the –d 5 argument. Instead we will specify the location of the binary in the Eclipse project. To do this remove the –d 5 and click on the Variables button. Then scroll down to the resource_loc variable and click on it. Now if you click on Run->External Tool->amplxe-local1 it will launch a amplxe-cl run data collection with whatever executable you have selected in your project.

External tool configuration #4 - Remote collection running on an embedded target for 5 seconds

In our last tool configuration we will launch a remote amplxe-cl collection on an embedded target. Again, Specify the values as previously stated but instead of the Variable resource_loc, this time specify string_prompt.  Before the $string_prompt variable specify the following syntax. –target ssh:root@${string_prompt} as specified below:

.

Now when you click on Run->External Tool->amplxe-remote it will bring a dialog to prompt you for the target where you want to launch your collection.

Summary

We have shown 4 ways that VTune Amplifier can easily be integrated into Eclipse. There are many such integrations possible. VTune Amplifier has a very powerful command-line and GUI that can be used to make working with VTune Amplifier in Eclipse relatively seamless. 

Загрузить статью

app-communication-ccefinal.pdf [Eng., 228.17 KB)

Аннотация

API WinRT в составе Windows 8 позволяет разработчикам быстро создавать и развертывать приложения, а затем публиковать их в магазине Windows. Если приложению нужен доступ к низкоуровневым системным ресурсам, требуются классические API Windows 8. Для обоих типов API разработчикам требуется создать два приложения (по одному для каждой среды) и каким-либо образом обеспечить обмен данными между ними. Для приложений, которые продаются в магазине Windows, этот обмен данными невозможно устроить локально. Вот что говорится в требованиях к сертификации приложений для магазина Windows:

3.1bПриложения для магазина Windows не должны обмениваться данными с локальными приложениями или службами посредством локальных механизмов, включая файлы и записи в реестре.

В этой статье рассматриваются способы обмена данными между десктопными и плиточными приложениями Windows 8. Приводятся основы реализации каждого подхода и соображения, которые следует учитывать при выборе. Если использовать сетевое подключение невозможно, то требование локального обмена данными не позволит выставить приложение в магазине Windows. Если есть интрасеть, можно использовать веб-службы или общее облако. При наличии доступа к Интернету крупные коммерческие решения могут использовать общее хранилище и другие веб-службы.

Общие сведения

Плиточные приложения Windows 8 должны быть компактными, надежными и быстрыми, а также должны поддерживать сенсорное управление. Для таких приложений действует ряд ограничений на доступ к различным компонентам файловой системы, ОС и оборудования. При обновлении существующих приложений до плиточной модели возникают некоторые препятствия. Часть функциональности приложений невозможно реализовать с помощью API WinRT API. Одно из возможных решений: создать интерфейс в стиле Windows 8, который будет обмениваться данными с десктопным приложением, чтобы выполнять действия, которые не поддерживаются в API WinRT. Есть несколько способов это сделать, но использование магазина Windows накладывает ряд ограничений.

Если компания разрабатывает собственные плиточные приложения Windows 8 для внутреннего использования, нет необходимости распространять их через магазин Windows. Значит, на эти приложения не действует запрет совместного доступа к локальным ресурсам. Дополнительные сведения см. по адресу http://blogs.msdn.com/b/windowsstore/archive/2012/04/25/deploying-metro-style-apps-to-businesses.aspx.

Соображения

Направление обмена данными

Если приложение просто предоставляет данные пользователям, данные будут передаваться главным образом (а может, и полностью) от десктопного приложения к плиточному. Обратная ситуация возникает довольно редко, но все же возможна. Если интерфейс более интерактивный, он должен как передавать данные во внутреннюю систему, так и получать данные оттуда.

Переключение между приложениями или фоновый обмен данными

Если требуется дискретный обмен данными, например сохранение файла в облегченном редакторе и переключение в полнофункциональный редактор, метод обмена данными может быть более статическим. При этом допускается больше вариантов реализации. При непрерывном обмене данными действует больше ограничений. Одно из важнейших ограничений: поток данных должен исходить из плиточного приложения Windows 8, которое используется в качестве интерфейса. Если же на переднем плане будет работать десктопное приложение, то плиточное будет, скорее всего, приостановлено. Приостановленное приложение, по сути, не работает: оно не может обмениваться данными и обрабатывать информацию.

Подключения

Если оба приложения находятся на одном и том же компьютере, количество возможных вариантов резко сокращается: многие способы обмена данными между процессами, доступные в прежних системах, не могут соединить WinRT с приложениями Win32. При добавлении интрасети появляется несколько дополнительных вариантов. Файлы можно хранить в локальном облаке или на серверном облачном хранилище, уведомления можно передавать через службу push-уведомлений Windows, можно использовать веб-службы. При наличии доступа в Интернет можно использовать крупные облачные хранилища и внешние веб-службы.

Автономная работа

Для общедоступного развертывания плиточного приложения Windows 8 это приложение необходимо сначала отправить в магазин Windows, для чего требуется пройти сертификацию. Десктопные приложения для Windows 8 также могут быть выставлены в магазине, но они должны быть автономными (не требовать установки других программных компонентов). Плиточные приложения Windows 8, выставленные в магазине Windows, могут зависеть от других программ, но только в случае, если эти программы также выставлены в магазине. Приложения для магазина Windows могут использовать другие программы (например, серверы, предоставляющие содержимое), но это может стать серьезным препятствием при совершенствовании приложений, работающих вместе. Десктопное приложение должно обладать, по крайней мере, мощной функциональностью, а плиточное приложение может служить вспомогательным компонентом (с дополнительной функциональностью) или в качестве расширения (более удобный доступ к уже существующим возможностям). Если внутренней обработкой занимается десктопное приложение, предоставляя содержимое плиточному приложению, то десктопному приложению также нужен свой интерфейс, чтобы оно могло работать автономно.

Возможные подходы

Веб-служба

Десктопное приложение может выполняться в качестве внутренней системы и предоставлять свои данные через веб-службу, что дает возможность плиточному приложению Windows 8 подключаться и обмениваться данными. Десктопное приложение также может служить посредником: обрабатывать взаимодействие и получать запросы по подключению. Пример использования веб-служб со стороны Windows 8 см. по адресу http://www.codeproject.com/Tips/482925/Accessing-Data-through-Web-Service-in-Windows-8-St.

Локальные файлы

Когда оба приложения находятся на одном и том же компьютере и пытаются обмениваться данными без использования сети, набор возможных вариантов весьма ограничен, но и эта задача решаема. Если приложение развертывается внутри компании, а магазин Windows не нужен, обмен данными можно осуществлять через локальные файлы, доступные для обоих приложений. Если десктопному приложению удастся обойти некоторые блокировки записи, оно сможет изменить общие файлы и обеспечить обмен информацией почти в реальном времени (если читать файлы быстро и часто). Пакет Intel Energy Checker SDK использует аналогичную модель (дополнительные сведения см. в разделе справочных материалов). В Windows 8 отключены именованные каналы, общая память и другие стандартные способы обмена данными между процессами. Поэтому остается, по сути, только использование локальных общих файлов. Опасность в этом случае заключается в раскрытии данных пользователям: поскольку файлы находятся в общей папке, пользователи могут получать к ним доступ, просматривать их и изменять. При этом возникают проблемы безопасности, если файлы не зашифрованы, и проблемы функциональности, если пользователь вдруг решит заблокировать, изменить или удалить файлы. Этот подход подробно описывается по адресу http://stackoverflow.com/questions/7465517/how-can-a-metro-app-in-windows-8-communicate-with-a-backend-desktop-app-on-the-s.

Облако: хранение и уведомления

При наличии доступа в сеть приложения могут обмениваться файлами с помощью удаленного сервера или облака. В большинстве облачных служб предусмотрены защитные механизмы, исключающие конфликты при доступе к файлам и утрату данных. Если настроить сервер push-уведомлений Windows (WNS), десктопное приложение сможет отправлять сообщения и обновления плиточному приложению Windows 8 в виде уведомлений. Это могут быть всплывающие уведомления, обновления динамических плиток; они могут обрабатываться кодом для настраиваемого обмена информацией. Примеры использования всплывающих уведомлений см. по адресу http://code.msdn.microsoft.com/windowsapps/Toast-notifications-sample-52eeba29Сведения об использовании облака см. по адресу http://www.windowsazure.com/en-us/develop/mobile/tutorials/get-started.

Имитация стиля

Если все перечисленные варианты неприменимы (например, используется один компьютер с ограниченными подключениями), можно полностью отказаться от реализации плиточного приложения Windows 8 и использовать только его плитку в качестве ярлыка для полноэкранного классического приложения, дизайн которого будет близок к стилю Windows 8. При этом не будут доступны все возможности Windows 8, но можно разрабатывать полнофункциональное приложение без ограничений, связанных с WinRT. Сведения и примеры таких приложений см. по адресу http://stackoverflow.com/questions/12881521/desktop-application-in-metro-style.

Тупики

Локальное замыкание веб-подключения

Локальное замыкание веб-подключения можно использовать приложениями в других ОС для подключения через веб-сокет к другой программе на этом же компьютере. В Windows 8 реализация этого подхода затруднена: механизмы безопасности Windows 8 отключают замыкание на себя. Эти механизмы безопасности можно отключить вручную, но лишь в режиме отладки. При этом приложение будет не только непригодно для распространения в коммерческих целях, но и никогда не пройдет сертификацию для магазина Windows.

Обмен данными в Win32

В Windows 8 можно упаковать API десктопных приложений в управляемые DLL-библиотеки для использования приложениями в стиле Windows 8. В теории это звучит неплохо, но на практике такой подход приводит к новым проблемам. В DLL-библиотеку придется упаковать целое приложение, из-за чего размер файла может достигнуть огромной величины. Если приложению требуется определенная функциональность Win32, не нарушающая политику сертификации магазина Windows, можно использовать собственную библиотеку. В определенных случаях добавление API в WinRT может сработать, но в качестве основной стратегии обмена данными между приложениями такой подход не годится.

Обзор возможных подходов

Заключение

Получить доступ к преимуществам плиточных приложений Windows 8 и десктопных приложений можно разными способами. Как это всегда бывает с программными решениями, одного лучшего варианта не существует. Выбор ограничивается различными факторами, но каждый метод имеет свои преимущества. Поскольку доступ к Интернету широко распространен, чаще всего используются веб-службы и облачные решения. Предоставленная здесь информация может служить отправной точкой для выбора наиболее подходящего решения. В будущем могут появиться и другие возможные варианты.

Прочие справочные материалы

Требования для сертификации приложений для Windows 8 http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx
Требования для сертификации классических приложений для Windows 8 http://msdn.microsoft.com/en-us/library/windows/desktop/hh749939.aspx
Требования для сертификации приложений для Windows Server http://msdn.microsoft.com/en-us/library/windows/desktop/hh848078(v=vs.85).aspx

Об авторе

Брэд Хилл (Brad Hill) — инженер по программному обеспечению в подразделении Developer Relations корпорации Intel. Брэд занимается изучением новых технологий на оборудовании Intel и обменивается лучшими методиками с разработчиками ПО на форумах Intel Developer Zone и на конференциях разработчиков. В настоящее время он работает над получением степени Ph.D по компьютерным наукам в Университете штата Аризона.

API выполняемого модуля Windows* WinRT является новым основным API приложений для Windows 8 Store*. Этот API раскрывает разработчикам все новые возможности Windows 8* с использованием высокоэффективного объектно-ориентированного принципа.

Этот API написан на C++ на основе Win32 и интерфейса COM. Доступ для других языков (в частности, C++/CX, C#, Visual Basic * и Javascript *) предоставляется посредством файлов метаданных API (с расширением *.winmd).

Может сложиться мнение, что API WinRT доступен только для приложений для магазина Windows 8*, но и классические приложения также имеют к нему доступ. Более того, некоторые компоненты API, например PackageManager, доступны только для классических приложений, поскольку их необходимо выполнять вне песочницы приложений для магазина Windows 8*. Получить сведения о доступности компонентов API можно непосредственно в библиотеке MSDN. В верхней части большинства классов указываются сведения о совместимости.

Для классических приложений остаются недоступными функции, предназначенные главным образом для приложений магазина Windows 8*: элементы дизайна и контакты.

WinRT предоставляет доступ к своему содержимому для других языков посредством двух основных WINMD-файлов:

• Windows.winmd: C:\Program Files (x86)\Windows Kits\8.0\References\CommonConfiguration\Neutral
• Platform.winmd: C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs\Microsoft.VCLibs\11.0\References\CommonConfiguration\neutral

Они соответствуют пространствам имен Windows и Platform. Пространство имен Windows предоставляет доступ к большинству функций среды выполнения Windows, а пространство имен Platform содержит важные типы, например String.

Вот некоторые полезные компоненты среды выполнения Windows, которые можно использовать из десктопных приложений:

• Windows.Sensors (акселерометр, гирометр, датчик освещенности, датчик ориентации и пр.)
• Windows.Networking.Proximity.ProximityDevice (NFC)
• Windows.Device.Geolocation (GPS)
• Windows.UI.Notifications.ToastNotification
• Windows.Globalization
• Windows.Security.Authentication.OnlineId (в том числе интеграция LiveID)
• Windows.Security.CryptographicBuffer (полезные функции кодирования и декодирования двоичных данных)
• Windows.ApplicationModel.DataTransfer.Clipboard (доступ к буферу обмена Windows 8 * и наблюдение за ним)

В этой статье вы узнаете, как использовать WinRT из десктопных проектов C#, а также из проектов C++/CXи на стандартном языке C++.

Использование среды выполнения Windows из проекта C#/.NET

По умолчанию среда разработки Visual Studio * 2012 не предоставляет доступ к среде выполнения Windows из обычных проектов десктопных приложений C#.

Прежде всего, необходимо объявить, что проект предназначен для Windows 8.

К сожалению, в VS2012 для этого не предусмотрен графический пользовательский интерфейс, поэтому сначала придется выгрузить проект C#:

Затем можно вручную отредактировать CSPROJ-файл, добавив в него следующее:

  <PropertyGroup>
    <TargetPlatformVersion>8.0</TargetPlatformVersion>
  </PropertyGroup>

Перезагрузите проект:

Теперь проект предназначен для Windows 8*. Из проекта можно ссылаться на WINMD-файлы:

В диспетчере ссылок должна появиться новая вкладка Windows:

Щелкните Windows, чтобы добавить Windows.winmd в качестве ссылки в проект. Если этот элемент отсутствует, можно вручную указать ссылку на его расположение (C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs\Microsoft.VCLibs\11.0\References\CommonConfiguration\neutral) с помощью кнопки «Обзор».

Теперь можно использовать среду выполнения Windows из классического приложения с полной поддержкой Intellisense:

Также может потребоваться добавить ссылку на System.Runtime.WindowsRuntime.dll, если вы используете сопоставленные типы , такие как обработчики событий среды выполнения Windows

Эта сборка находится в папке C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5 .

Пример работы с акселерометром с помощью WinRT C#/.NET

using System;
using Windows.Devices.Sensors;
namespace CSApp
{
    class Program
    {
        static void Main()
        {
            Accelerometer accelero = Accelerometer.GetDefault();
            accelero.ReadingChanged += (Accelerometer sender, AccelerometerReadingChangedEventArgs args) =>
                {
                    Console.WriteLine(args.Reading.AccelerationX);
                };
            Console.Read();
        }
    }
}

Использование среды выполнения Windows из проекта C++

Можно использовать API WinRT из C++/CX или из стандартного C++. При использовании стандартного C++ потребуется использовать WRL (библиотеку шаблонов C++ среды выполнения Windows) и напрямую обрабатывать объекты COM.

Оба решения создают собственный код, но использование WRL отличается намного более высокой трудоемкостью по сравнению с C++/CX.

Решение C++/CX

Решение C++/CX во многом близко к C++/CLI. Основное отличие от C++/CLI заключается в том, что C++/CX вообще не создает управляемый код; образуется только собственный код.

Общую документацию по C++/CX см. в библиотеке MSDN. Для начала можно использовать краткий справочник.

#using <Windows.winmd>
 #using <Platform.winmd>

#include <iostream>
#using <Windows.winmd>
using namespace Windows::Devices::Sensors;
#using <Platform.winmd>
using namespace Platform;

[MTAThread]
int main(void)
{
 Accelerometer^ accelero = Accelerometer::GetDefault();
 accelero->ReadingChanged += ref new Windows::Foundation::TypedEventHandler<Accelerometer^,AccelerometerReadingChangedEventArgs^>(
 [](Accelerometer^ sender, AccelerometerReadingChangedEventArgs^ args){
 std::cout << args->Reading->AccelerationX << std::endl;
 });
 std::cin.get();
 return 0;
}

Загрузить статью

Windows* 8 Desktop App - Low Power Audio Playback [Eng., PDF]

Введение

Один из распространенных сценариев использования планшетов с процессорами Intel® Atom™ под управлением Microsoft Windows 8* — воспроизведение музыки в режиме пониженного энергопотребления. Эта возможность позволяет пользователям продолжать слушать музыку после перехода устройства в состояние пониженного потребления электроэнергии, которое называется Connected Standby. Connected Standby — это сценарий «всегда включен, всегда подключен», реализованный в Microsoft Windows и запускаемый с помощью новых состояний пониженного потребления электроэнергии процессоров Intel Atom S0ix. В этом состоянии устройства могут гораздо дольше работать от аккумуляторов, при этом пользователи по-прежнему могут слушать музыку.

Мы продемонстрируем создание приложения HTML5 и JavaScript*, позволяющее простому приложению для воспроизведения музыки работать в режиме ожидания с подключением.

Общие сведения о режиме Connected Standby

(Автор описания: Priya Vaidya)

Connected Standby предназначен главным образом для снижения энергопотребления и для продления времени работы устройств от аккумулятора. Этот режим сертифицируется Microsoft; устройства должны соответствовать требованиям корпорации. Устройство переходит в режим Connected Standby при нажатии кнопки питания или после бездействия в течение определенного времени. В текущих тестах потребляемая мощность составляет < 100 мВт¹ , потребляемая мощность процессора Intel Atom Z2760 (кодовое название Clover Trail) — около 45 мВт (что соответствует работе в режиме ожидания с подключением в течение примерно 30 дней). Это требование корпорации Microsoft. Согласно требованию «мгновенного включения», должно пройти не более 300 мс¹с момента нажатия кнопки до включения экрана. С точки зрения системы в целом платформа находится в спящем режиме, только изредка запускаются отдельные приложения.

Connected Standby — последовательность действий

Написание кода приложения HTML5

Один из самых простых способов написания кода для воспроизведения звука с пониженным энергопотребления на планшетах с процессорами Intel Atom под управлением Windows 8 — использование нового тега HTML5 audio. По умолчанию тег audio НЕ продолжает воспроизведение при переходе в режим Connected Standby. Чтобы включить воспроизведение звука в этом состоянии, тег HTML должен содержать атрибут категории звука. Имя этого атрибута — msAudioCategory, для него необходимо задать значение BackgroundCapableMedia. Этого достаточно, чтобы все было готово для воспроизведения в режиме Connected Standby.

Кроме того, для правильной работы воспроизведения звука с пониженным энергопотреблением необходимо изменить манифест приложения. Требуется добавить объявление Background Tasks. В этом объявлении также нужно задать свойство для audio. При использовании Visual Studio* это делается очень просто: нужно открыть package.appxmanifest, перейти на вкладку «Объявления», добавить объявление Background Tasksиз раскрывающегося списка «Доступные объявления», а затем выбрать тип задачи Audioв разделе «Свойства».

Этот способ создания кода показан в образце приложения Low-Power в файлах default.html и default.js. Правильное объявление также содержится в файле package.appxmanifest. В примере также использован атрибут Controlдля автоматического добавления простых элементов управления воспроизведением.

Воспроизведение аудиофайлов с аппаратным ускорением обработки

Говоря о воспроизведении звука на платформе Intel Atom с пониженным потреблением электроэнергии, следует упомянуть и об аппаратном ускорении декодирования звука. Платформа Clover Trail обладает аппаратной поддержкой кодирования и декодирования целого ряда форматов аудиофайлов.

Итоги

Воспроизведение звука с пониженным потреблением электроэнергии — полезная возможность мобильных устройств, позволяющая использовать их в качестве обычных музыкальных плееров со значительным сроком работы от аккумуляторов. С помощью нового тега audio в HTML5 и JavaScript можно без труда добавлять эту функциональность в приложения как статически, так и динамически.

Writing Energy-Efficient Windows* Store Applications for Mobile Devices [Eng., PDF 753KB]

1. Введение

В настоящее время повсеместно применяются различные мобильные устройства: смартфоны, планшеты, ультрабуки и т. п. Все они работают от аккумуляторов. Время работы от аккумулятора крайне важно для конечных пользователей: всем хочется, чтобы устройство работало без подзарядки как можно дольше.

Проблемы энергоэффективности напрямую влияют на время работы от аккумулятора. На этот показатель влияет весь набор мобильных программных приложений. Мобильные приложения, будучи важной составляющей набора программного обеспечения, играют важную роль в энергопотреблении всей платформой. Задача разработчиков приложений заключается в том, чтобы создавать приложения, экономно расходующие электроэнергию, что позволит дольше использовать устройства без подзарядки.

Различные приложения могут влиять на энергопотребление различными компонентами оборудования: CPU, GPU, устройством хранения данных, сетевым адаптером, датчиками и пр. В серии статей, посвященных экономии электроэнергии, мы обсудим правила проектирования энергоэффективных приложений для различных аппаратных компонентов. Это руководство основано на серии лучших методик для примеров приложений для магазина Windows с реализацией функций и классов в новом наборе API — среде выполнения Windows (WinRT).

В этой статье мы рассматриваем влияние потребления питания центральным процессором. Сначала мы поговорим о состояниях энергопотребления процессора, а затем обсуждим влияние определенных API WinRT на работу CPU.

2. Состояния энергопотребления процессора

Современные процессоры поддерживают несколько состояний энергопотребления. Все эти состояния можно разделить на две категории: активные состояния и состояния сна. Активное состояние включает несколько рабочих состояний (P-состояний), которые различаются напряжением питания и частотой процессора. Состояние сна включает несколько C-состояний (Cx-состояний), которые различаются уровнем экономии энергии. Подробные определения активных состояний и состояний сна см. в технических спецификациях процессоров на базе архитектуры IA.

2.1 Активное состояние

Активное состояние (состояние C0) означает, что процессор выполняет инструкции. Активное состояние включает несколько P-состояний, различающихся напряжением питания и частотой процессора. Каждому P-состоянию соответствует определенное напряжение питания и определенная частота CPU. В более высоком P-состоянии выше и напряжение питания, и частота. Динамические потребление электроэнергии в определенном P-состоянии можно вычислить с помощью следующего уравнения:

P = C_dynV²F

где P— динамическое потребление электроэнергии в определенном P-состоянии. C_dyn— динамическая нагрузка на CPU. Vи F, соответственно, напряжение питания и частота CPU в данном P-состоянии. Из этого уравнения следует, что в более высоком P-состоянии CPU потребляет больше электроэнергии.

2.2 Состояние сна

Бездействующий процессор переходит в состояние сна для экономии электроэнергии. Многие процессоры на основе архитектуры IA поддерживают несколько состояний сна (так называемых Cx-состояний), например C1, C2/C3, C5, C6 и C7. В состоянии C1 процессор обычно остановлен, поскольку не нужно выполнять никакие инструкции. Состояние C2/C3, если поддерживается, обеспечивает пониженное потребление электроэнергии по сравнению с состоянием C1. В состоянии C2/C3 кэш процессора остается включенным, а основные функции отключены. Состояния C5/C6/C7 (если поддерживаются) — дополнительные состояния глубокого сна. По мере перехода из состояния C1 в состояние C7 потребляемая процессором мощность снижается, но увеличивается задержка при пробуждении процессора.

2.3 Управление состояниями энергопотребления

Состояниями энергопотребления управляет драйвер процессора и операционная система. Для экономии электроэнергии широко применяется типовой механизм планирования. Обратите внимание, что механизм планирования в современных операционных системах и драйверах процессоров устроен сложнее описываемого здесь. Когда процессор активен, но используется не на полную мощность, он переходит в более низкое Р-состояние для экономии электроэнергии. При длительном сроке резидентности бездействия процессор переходит в состояние более глубокого сна для экономии энергопотребления. Разработчики приложений могут снизить нагрузку на CPU и использовать менее частое обновление таймера, чтобы сократить потребление электроэнергии процессором.

2.4 Проведение эксперимента

Мы провели тесты с использованием типового таймера в приложении для магазина Windows. Тесты были проведены на ультрабуке с процессором Intel® Core™ 3-го поколения и с чистой установкой коммерческой версии Windows 8. Для измерения потребляемой мощности мы использовали Intel® Power Gadget. Скорость обновления экрана платформы — 60 кадров в секунду (кадр/с).

3. Влияние таймеров

Как правило, при более высокой частоте таймеров приложений процессоры чаще пробуждаются и активнее используются. Применение периодического таймера может существенно повлиять на потребляемую процессором мощность. Ниже описывается влияние периодического таймера в приложении для магазина Windows на потребляемую мощность процессора.

3.1 Создание и отмена таймера пула потоков

Среда выполнения Windows включает класс ThreadPoolTimer. Программные таймеры в приложениях можно создавать путем вызова функций CreateTimerили CreatePeriodicTimerв этом классе. Таймеры широко используются для создания потоков в приложениях для магазина Windows. Мы реализовали периодический таймер путем вызова функции CreatePeriodicTimer.

В примере кода показано использование API для создания периодического таймера.

private void CreatePeriodicTimer(object sender, RoutedEventArgs args)
{
     if (int.TryParse(PeriodMs.SelectionBoxItem.ToString(), 
         out ThreadPoolSample.PeriodicTimerMilliseconds))
     {
      ThreadPoolSample.PeriodicTimer = ThreadPoolTimer.CreatePeriodicTimer(
          (timer) => {
          System.Threading.Interlocked.Increment(ref   
              ThreadPoolSample.PeriodicTimerCount);
              Dispatcher.RunAsync(
                  CoreDispatcherPriority.High, () =>
                  {                                  
                       ThreadPoolSample.PeriodicTimerScenario.UpdateUI(
                       Status.Completed);
                  });
      },
      TimeSpan.FromMilliseconds(
          ThreadPoolSample.PeriodicTimerMilliseconds));
      UpdateUI(Status.Started); //Do nothing or update XAML textbox
}

Образец кода 1. Создание периодического таймера с помощью класса ThreadPoolTimer **

В примере кода показано использование API для отмены периодического таймера.

private void CancelPeriodicTimer(object sender, RoutedEventArgs args)
{
     if (ThreadPoolSample.PeriodicTimer != null)
     {
         ThreadPoolSample.PeriodicTimer.Cancel();
         ThreadPoolSample.PeriodicTimerCount = 0;
         UpdateUI(Status.Canceled);
     }
}

Образец кода 2. Отмена периодического таймера с помощью класса ThreadPoolTimer **

3.2 Влияние интервала периодического таймера

Мы сравниваем периодические таймеры с различными интервалами, срабатывающие без нагрузки и с простым обновлением текстового поля в пользовательском интерфейсе XAML. На рис. 1 показано среднее энергопотребления процессором по отношению к расходу электроэнергии при простое процессора в различных тестах.

Рисунок 1. Влияние интервала периодического таймера на потребляемую мощность CPU

Когда периодические таймеры срабатывают без нагрузки, потребление питания процессором близко к состоянию простоя даже при разной частоте таймеров. Это означает, что драйвер процессора и операционная система оптимизируют планирование работы таймера и поддерживают пониженный расход электроэнергии для процессора при незначительной нагрузке. Когда таймеры срабатывают с простым обновлением пользовательского интерфейса, по мере сокращения интервала таймера потребляемая мощность процессора увеличивается по экспоненте и в 1,72 раза превышает потребляемую мощность в режиме простоя. График роста потребления электроэнергии позволяет узнать, какие механизмы запускаются периодическим таймером в приложении. Рекомендуем разработчикам тщательно подходить к выбору интервала таймера, чтобы удовлетворить требованиям приложения без излишней нагрузки на CPU. Ненужный таймер необходимо отключать.

3.3 Резидентность P- и C-состояний

Резидентность P- и C-состояний указывает процент времени, в течение которого процессор остается в определенном Р- или С-состоянии. Как правило, сумма всех резидентностей С-состояний (С0–С7) равна 100 %, как и сумма всех резидентностей Р-состояний. Для примера с периодическим таймером, срабатывающим для простого обновления XAML, данные о резидентности Р- и С-состояний приведены в таблице 1.

Таблица 1. Резидентность P- и C-состояний для периодического таймера, срабатывающего для обновления пользовательского интерфейса

В таблице 1 видно, что при небольшом значении интервала таймера (5 или 16 мс) резидентность состояния C7 равна нулю: из-за слишком частого срабатывания таймеров процессор вообще не переходит в состояние глубокого сна. Для обновления пользовательского интерфейса процессор должен пробудиться из состояния С6. Если увеличить интервал таймера (20 или 100 мс), процессор проводит около 70 % времени в состоянии C7. Таким образом, потребляемая мощность процессора снижается в состоянии сна.

Значение резидентности P-состояния указывает, что при кратких интервалах таймера процессор работает 100 % активного времени с номинальной частотой. Обратите внимание, что режим работы с номинальной частотой отнюдь не является наиболее низким Р-состоянием. Если же увеличить интервал таймера, процессор может перейти в более низкое Р-состояние. Таким образом, потребляемая мощность процессора снижается в активном состоянии.

Следовательно, интервалы программных таймеров, связанных с нагрузкой, существенно влияют на резидентность Р- и С-состояний. Мы рекомендуем разработчикам приложений следить за резидентностью Р- и С-состояний, чтобы снизить потребление мощности, вызванное приложением, если непосредственное измерение потребляемой мощности процессора недоступно.

4. Сравнение ThreadPoolTimerи DispatcherTimer

Среда выполнения Windows предоставляет еще один таймер в классе Windows.UI.Xaml.DispatcherTimer. Сравним работу этих двух классов при простом обновлении пользовательского интерфейса XAML. Класс DispatcherTimer предоставляет таймер, интегрированный в очередь диспетчера, которая обрабатывается с заданным интервалом времени и с заданным приоритетом.

4.1 Создание и отмена таймера диспетчера

DispatcherTimerсоздается, как показано в приведенном ниже образце кода.

private void CreateDispatcherTimer(object sender, RoutedEventArgs args)
{        
    if (int.TryParse(PeriodMs.SelectionBoxItem.ToString(), 
         out ThreadPoolSample.PeriodicTimerMilliseconds))
         {
             dispatcherTimer = new DispatcherTimer();
             dispatcherTimer.Tick += UpdateUIwithDispatcherTimer;
             dispatcherTimer.Interval = TimeSpan.FromMilliseconds(
                 ThreadPoolSample.PeriodicTimerMilliseconds);
             dispatcherTimer.Start();
         }
}

Образец кода 3. Создание периодического таймера с помощью класса DispatcherTimer **

private void CancelDispatcherTimer(object sender, RoutedEventArgs args)
{
    dispatcherTimer.Stop();
}

Образец кода 4. Отмена таймера с помощью класса DispatcherTimer **

4.2 Кадровая скорость потока пользовательского интерфейса и сравнение энергопотребления

Мы реализуем два таймера в приложении для магазина Windows, чтобы обновлять простое текстовое поле XAML с различными периодическими интервалами. Сравнение кадровой скорости потока пользовательского интерфейса и потребляемой мощности процессора показано на рис. 2. Ломаные линии представляют среднюю потребляемую мощность процессора по сравнению с потреблением в режиме простоя. Столбцы представляют кадровую скорость потока пользовательского интерфейса, с этой скоростью обновляется текстовое поле XAML.

Рисунок 2. Сравнение кадровой скорости потока пользовательского интерфейса и потребляемой мощности CPU для двух реализаций в приложении для магазина Windows*

Из графика видно, что при определенном интервале таймера процессор потребляет меньше электроэнергии при использовании таймера DispatcherTimer. Это обусловлено тем, что класс DispatcherTimer ограничивает кадровую скорость потока пользовательского интерфейса (30 кадр/с) половиной скорости обновления экрана (60 кадр/с). Поэтому мы рекомендуем разработчикам приложений использовать класс DispatcherTimer для обновления пользовательского интерфейса.

5. Итоги

В этой статье описываются доступные состояния энергопотребления процессора. Затем обсуждается экономия электроэнергии, потребляемой процессором, в приложениях для магазина Windows. Мы рассчитываем, что разработчики смогут воспользоваться этими советами при разработке программного обеспечения.

6. Дальнейшее обсуждение

Как было упомянуто во введении, в дальнейших статьях этой серии мы обсудим влияние других компонентов оборудования на потребление электроэнергии. Мы рассмотрим меры по повышению энергоэффективности в различных типах приложений для магазина Windows, таких как приложения с интенсивной обработкой графики, приложения для доступа к файлам, приложения для передачи данных по сети, приложения для обработки данных датчиков и пр.

7. Об авторе

Сушу Чжанг (Sushu Zhang) работает программистом в подразделении Intel по разработке ПО и обслуживанию. Она занимается вопросами интеграции платформ на базе Intel с ОС Android и Windows в ISV. Ею разработан инструмент Intel® Power Monitoring Tool для устройств Android. В последнее время Сушу принимала участие в нескольких проектах Intel по оптимизации энергопотребления. До перехода в Intel она работала в корпорации Майкрософт и занималась энергоэффективностью Windows. Сушу получила степень доктора наук по компьютерным наукам в Университете штата Аризона. Областью ее научных интересов были энергопотребление систем и управление рабочими температурами.

Copyright© 2012 Intel Corporation. All rights reserved.

КРАТКИЙ БИЗНЕС-ОБЗОР
Intel® Developer Zone
Процессор Intel® Atom™ серии Z3700
Microsoft Windows* 8.1

Загрузить в формате PDF

Усовершенствования ОС Microsoft Windows 8 и внедрение разработок SoC (system-on-chip) на основе процессоров Intel® Atom™ серии Z3700 предоставляют разработчикам программного обеспечения возможность создавать инновационные приложения.

Быстрое внедрение планшетных ПК меняет технологическую инфраструктуру. Отчет Дженнифера Кента (Jennifer Kent), аналитика Parks Associates Research, за третий квартал 2013 г.: "Всего за три года планшетные ПК заняли около трети американского потребительского рынка широкополосной связи, наряду с расширением спектра устройств и цен, из года в год стимулирующих рост продаж".¹

Вместе с сохранением этой тенденции многим потребителям необходимы возможности планшетов для надежной работы с привычными семейными приложениями и поддержкой передовых игровых программ вместе с предложением следующего поколения графических решений. Учитывая эти требования, ОС Windows, работающая на процессорах Intel®, представляет собой комбинацию возможностей, на которые пользователи могут обратить свое внимание в первую очередь.

Как показано на рисунке 1, прогнозируемый приход на рынок планшетных ПК под управлением Windows составляет ежегодно 42-процентный прирост (CAGR) до 2016,²демонстрируя, в целом, максимум преимуществ от использования планшетных устройств.

Рисунок 1.Тенденции: планшеты под управлением Windows*.

Этот общий позитивный настрой приветствуется разработчиками программного обеспечения, которые останутся в выигрыше от общего растущего рынка приложений для Windows. Обширный опыт в области разработок, инструментальные средства и поддержка экосистемой ОС Windows определяют направление развития в помощь для достижения успеха на рынке.

Вкладом в дальнейшее развитие планшетных ПК на основе Window также является разработка систем SoC (system-on-chips), основанных на процессорах Intel® Atom™ серии Z3700.

Системы SoC содержат такие элементы, как интегрированное решение HD-графики Intel®, технология Intel® Wireless Display,³и широкие возможности подключения с помощью 4G LTE. Технология ISP 2.0 (Image Signal Processing) помогает упростить вызовы библиотечных функций, например, Intel® Integrated Performance Primitives, давая разработчикам свободу в создании особенно необходимых и ценных функциональностей.

Тенденции возможностей потребителей в праздничном сезоне 2013 года

Разработчики сейчас работают над созданием приложений, которые в этот праздничный сезон предложат пользователям самые новые возможности интерфейсов взаимодействия. Системы SoC, создаваемые на основе следующего поколения процессоров Intel Atom на базе 22-нм технологии, предлагают беспрецедентные возможности для планшетных ПК, в числе которых:

• Удивительная производительность.Быстрота и оперативность выполнения приложений для настольных ПК и приобретаемых в магазине Windows Store.
• Невероятная продолжительная автономная работа от батареи.Высочайшая энергоэффективность для долгой автономной работы от батареи.
• Великолепные видеовозможности.Ускоренная HD-графика и видео, технология Intel Wireless Display.³
• Многоуровневая безопасность.Аппаратная и программная защита для устройств, данных и персональной информации.

Узнайте больше о разработках для ОС Windows и процессоров Intel Atom на сайте software.intel.com/ru-ru/windows.

¹ Parks Associates, "Планшетные ПК: Пришествие мобильных вычислений и цифровой дом"Дженнифер Кент (Jennifer Kent) и Кристофер Кофман (Christopher Coffman), третий квартал 2013 г.

² Strategy Analytics, 2013 г.

³Требуется система с поддержкой технологии Intel® Wireless Display (Intel® WiDi), совместимый адаптер и телевизор Воспроизведение данных в формате 1080p и Blu-Ray* или другого защищенного содержимого доступно только на системах на базе процессоров Intel® Core™ со встроенным графическим решением, совместимым адаптером и медиапроигрывателем, а также с помощью ПО, имеющего поддержку технологии Intel® WiDi и установленного драйвера графики. Проконсультируйтесь с производителем ПК. Для получения дополнительной информации см. страницу http://www.intel.ru/content/www/ru/ru/architecture-and-technology/intel-wireless-display.html.

Содержание

1. Введение
2. Алгоритм портирования приложений
3. Создание приложения HTML5 в Visual Studio 2012*
4. Необходимые файлы
5. Выбор возможностей устройства, необходимых для приложений HTML5
6. Структура каталогов и тестирование приложений HTML5 в Visual Studio 2012
7. Обнаруженные проблемы

Введение

Эта статья предназначена для начинающих разработчиков HTML5. В ней описывается процесс портирования приложений HTML5, входящих в состав среды разработки Intel(R) HTML5. Тем, кто никогда не работал с HTML5, можно для начала ознакомиться со следующими материалами: http://software.intel.com/en-us/html5.
Мы портировали следующие приложения HTML5 для Windows 8* Store:

• Counting Beads
• RPN Calculator
• Towers of Hanoi
• jQM Springboard Nav

На момент написания этой статьи приложение PhoneGap Build* не поддерживало размещение в Windows 8 Store.

Алгоритм портирования приложений

Портирование приложений HTML5 для Windows 8* Store несложно, если приложения уже были преобразованы для Internet Explorer* 10 (IE10). Впрочем, может потребоваться немало времени, чтобы добиться работоспособности приложения во всех браузерах. Мы реализуем следующие шаги:

1. Сначала нужно преобразовать приложение для IE10
   Проверьте, какие функции поддерживаются в IE10, открыв ссылку http://html5test.com/в IE10. Узнайте, какие проблемы могут возникнуть.
   Встреченные нами проблемы перечислены в разделе советов.
2. Создание пустого приложения JavaScript в Visual Studio 2012*
   Мы использовали Visual Studio 2012 Express Edition на компьютере с Windows 8. Подробные описания использованных средств см. в разделе Microsoft MSDN Get the tools (Windows Store apps).
3. Добавление файлов в пустой проект JavaScript
4. Выбор нужных функций устройства
5. Тестирование

Создание приложения HTML5 в Visual Studio 2012

Приложение HTML5 в Windows 8 может быть создано следующим образом:

1. Создайте новый проект JavaScript — BlankApp
   Будет создан проект JavaScript с пустым содержимым и множеством файлов по умолчанию.
2. Переименуйте default.html в index.html.
   Файл default.html — это начальная страница, создаваемая по умолчанию. Чтобы переименовать файл, щелкните его правой кнопкой мыши и выберите команду «Переименовать».
3. Установите файл index.html в качестве начальной страницы пакета.
   Дважды щелкните файл package.appxmanifest. Он будет открыт в редакторе манифеста. Измените значение свойства «Начальная страница» с default.html на index.hmtl:
   
4. Переименуйте папку images в win8-images и обновите следующие изображения образца приложения HTML5
   • logo.png
   • smalllogo.png
   • storelogo.png
   • splashscreen.png
5. Удалите ненужные файлы: default.css и default.js.
6. Скопируйте файлы из образца приложения HTML5 в корневую папку проекта.
7. Добавьте файлы из образца приложения HTML5.
   Это может занять некоторое время, поскольку для правильной упаковки приложения нужно добавить все папки и файлы.
8. Щелкните «Run on Local Machine» или «Run on Simulator».

При этом вам может пригодиться информация со следующей страницы MSDN: Create your first Windows Store app using JavaScript .

Необходимые файлы

При создании приложений Windows 8 Store следует соблюдать ряд требований. Полный контрольный список для отправки приложений находится на странице MSDN.

При разработке и тестировании требуются 4 файла с логотипом:

Если выбрать один из готовых типов проектов в Visual Studio 2012, нужные файлы изображений будут по умолчанию созданы с нужным размером.

Выбор возможностей устройства, необходимых для приложений HTML5

Функции устройств для приложений Windows 8 Store объявляются в файле манифеста package.appxmanifest. Этот файл создается по умолчанию в Visual Studio 2012. Функции устройств в приложениях Windows 8 Store отличаются от функций устройств в приложениях PhoneGap. Поэтому нужно аккуратно перенести их из файла config.xml приложения PhoneGap в файл package.appxmanifest.
На следующем рисунке показан список функций устройств в Visual Studio 2012.

Ниже перечислены все функции устройств, использованные в файле "config.xml"приложения PhoneGap's :

<!-- If you do not want any permissions to be added to your app, add the
    following tag to your config.xml; you will still have the INTERNET
    permission on your app, which PhoneGap requires. -->
<preference name="permissions" value="none"/>

<!-- to enable individual permissions use the following examples -->
<feature name="http://api.phonegap.com/1.0/battery"/>
<feature name="http://api.phonegap.com/1.0/camera"/>
<feature name="http://api.phonegap.com/1.0/contacts"/>
<feature name="http://api.phonegap.com/1.0/file"/>
<feature name="http://api.phonegap.com/1.0/geolocation"/>
<feature name="http://api.phonegap.com/1.0/media"/>
<feature name="http://api.phonegap.com/1.0/network"/>
<feature name="http://api.phonegap.com/1.0/notification"/>

Например, для приложения HTML5, записывающего и воспроизводящего звук, файл package.appxmanifest должен содержать следующие функции:

• Микрофон
• Библиотека музыки

Для файла config.xml приложения PhoneGap требуется только следующее:

• <feature name="http://api.phonegap.com/1.0/media"/>

Структура каталогов и тестирование приложений HTML5 в Visual Studio 2012

Добавление всех необходимых папок и файлов в проекты занимает немало времени. Поэтому для вашего удобства мы включили файлы проектов Visual Studio 2012* в образцы приложений HTML5, преобразованных для Windows 8 Store. Структура папок выглядит следующим образом:

Сборка приложения в Visual Studio 2012 для магазина Windows 8:

1. Скопируйте файлы проекта из win8-proj в корневую папку
2. Загрузите JSPPROJ-файл в Visual Studio 2012 и запустите его в среде разработки

Обнаруженные проблемы

1. При преобразовании приложений для IE10 большая часть обнаруженных проблем была связана с градиентом в каскадных таблицах стилей, например, при добавлении -ms-linear-gradient в следующем случае:
   

       background: -moz-linear-gradient(top,#7A987E 0%,#000000);
       background: -webkit-gradient(linear, left top, left bottom, from(#7A987E),to(#000000));
       background: -ms-linear-gradient(top, #7A987E, #000000);  /* IE10 */
   
   

2. 3. Следующая проблема относится к jQuery-1.8.x.js. При использовании обычного компонента jQuery со страницы "http://jquery.com/download/"появится следующая ошибка Visual Studio 2012:
   "HTML1701: Unable to add dynamic content". Сценарий попытался внедрить динамическое содержимое или элементы, которые ранее изменялись динамически, что может быть небезопасно. Например, использование свойства innerHTML или метода document.write для добавления элемента сценария вызовет это исключение. Используйте метод toStaticHTML для фильтрации динамического содержимого или явным образом создайте элементы и атрибуты таким методом как createElement. Дополнительные сведения см. по ссылке "http://go.microsoft.com/fwlink/?LinkID=247104".
   
   Мы столкнулись с этой проблемой в jqm-springboard-nav. Версию jQuery для приложений Windows 8 Store можно загрузить по адресу "https://github.com/appendto/jquery-win8". В приложении jqm-springboard-nav мы использовали следующий код:
   

   <script>
       function includeJavaScript( url ){
           var tag = document.createElement( 'script' );
           tag.type = "text/javascript";
           tag.src = url;
   
           // Insert it to the <head>
           document.getElementsByTagName("head")[0].appendChild( tag );
       }
       </script>
   
       <!-- note: use jquery-1.8.0.min.js & jquery.mobile-1.1.1.min.js for production -->
       <script>
   	if (deviceCheck.windows8) {
   	    includeJavaScript("vendor/jquery/jquery-1.8.2-win8-1.0.js");
   	}
   	else {
   	    includeJavaScript("vendor/jquery/jquery-1.8.0.js");
   	}
       setTimeout(function(){
       	includeJavaScript("vendor/jquery.mobile/jquery.mobile-1.1.1.js");
   		includeJavaScript("app/springboard.js");
           }, 100);
       </script>
   
   

Но при преобразовании приложения HTML5 Counting Beads возникли более серьезные проблемы, поскольку это приложение изначально работает только в Chrome. Подробные сведения о преобразовании образца приложения Counting Beads приведены в этой статье.

Скачать статью

Скачать статью Porting Advanced User Interfaces From iOS* To Windows 8* [Eng., PDF 620KB]

Аннотация

В этой статье описывается процесс портирования сложных пользовательских интерфейсов с iOS на Windows 8. В качестве примера мы используем приложение для обработки электронных медицинских карт (EMR).

1 Введение

За последние годы планшеты как новая разновидность мобильных компьютерных платформ быстро вышли за пределы потребительского рынка и активно используются в бизнесе и в корпоративных системах. После выпуска операционной системы Windows 8 мы решили предложить разработчикам несколько кратких руководств, которые помогли бы перенести существующие приложения с других платформ, таких как iOS, на Windows 8, а также начать разработку новых приложений для ультрабуков, планшетов и других устройств с архитектурой Intel под управлением Windows 8. Данная статья также преследует эту цель и описывает расширенные возможности пользовательских интерфейсов.

Для iOS основным языком разработки является Objective-C. Для приложений для магазина Windows можно использовать различные средства и языки разработки, в том числе Visual C#, HTML/JavaScript * и прочее. В этом примере мы используем Visual C#* в качестве языка разработки.

1.1 От Xcode * 4 к Visual Studio * 2012

Аналогично тому, как разработчики приложений для iOS используют пакет средств разработки Xcode под управлением OS X *, разработчики приложений для Магазина Windows используют интегрированную среду разработки Visual Studio 2012. Есть аналог и поддерживающему раскадровку средству проектирования интерфейсов Interface Building, применяемому в Xcode 4 (рис. 1): в состав Visual Studio 2012 входит средство XAML Designer (рис. 2).

Рисунок 1. Interface Builder в Xcode 4

Рисунок 2. XAML Designer в Visual Studio 2012

1.2 Пример проекта

Это одна из статей, в основе которых лежит пример проекта. В проекте (ссылка на папку и другие статьи на основе этого проекта) мы перенесли приложение для управления электронными медицинскими картами с iOS на Windows 8. Вот основные требования к приложению:

• Отображение списка пациентов
• Отображение личной и медицинской информации о каждом пациенте: личные данные, оплата счетов, основные физиологические показатели, результаты анализов, снимки и пр.
• Отображение подробных графиков и изображений при выборе соответствующих элементов

Данная статья посвящена расширенным возможностям пользовательского интерфейса этого проекта.

2 Общие принципы устройства пользовательского интерфейса и навигации

В iOS можно использовать контроллер раздельного представления, чтобы отобразить на экране общее и подробное представления. Для группировки информации по категориям можно использовать табличные представления или вкладки. На рис. 3. показано раздельное представление с общим и подробным табличным представлением. В левой части раздельного представления показан прокручиваемый список пациентов. В правой части — медицинские записи, связанные с пациентом, выбранным в списке. Для отображения категорий медицинских записей в одном представлении мы используем табличное представление. Также можно использовать представление вкладок и отображать на каждой вкладке определенную категорию медицинских записей. На рис. 4 показано создание такого представления с помощью раскадровки Xcode 4.

Рисунок 3. Интерфейс в iOS: контроллер раздельного представления, общее табличное представление и подробное табличное представление

Рисунок 4. Используйте раскадровку Xcode для создания раздельного представления, общего и подробного табличного представлений

В приложении для магазина Windows мы можем получить такой же результат, используя иерархическую систему навигации (рис. 5). На странице первого уровня показано табличное представление с плиткой для каждого пациента (рис. 6). Страница второго уровня содержит сгруппированные элементы — медицинские записи пациента, выбранного на странице первого уровня (рис. 7). Страница третьего уровня содержит сгруппированные данные — определенную категорию медицинских записей, выбранных на странице второго уровня (рис. 8). Также может быть страница четвертого уровня с подробной информацией каждого элемента, например с фактическим изображением рентгеновского снимка, выбранного на странице третьего уровня.

Рисунок 5. Иерархическая система навигации в приложении для магазина Windows.

Рисунок 6. В приложении для магазина Windows в представлении корневого уровня находятся плитки списка пациентов.

Рисунок 7. В приложении для магазина Windows на странице второго уровня отображаются медицинские записи, связанные с выбранным пациентом.

Рисунок 8. В приложении для магазина Windows на странице третьего уровня отображается группа, выбранная на странице второго уровня.

В проектах Visual Studio 2012 страница пользовательского интерфейса определяется в XAML-файле, с которым связан файл кода C# (CS-файл). Поскольку переходы с одной страницы на другую обычно вызваны действиями пользователей, например при нажатии элемента табличного представления, для управления навигацией целесообразно использовать прослушиватели событий. На рис. 9 показана страница первого уровня PatientsListPage, где мы определяем прослушиватель событий ItemsGridView_ItemClick.

[xml]
<common:LayoutAwarePage
x:Name="pageRoot"
x:Class="PRApp.PatientsListPage"
DataContext="{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:PRApp"
xmlns:common="using:PRApp.Common"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d">

…
<GridView
x:Name="itemGridView"
AutomationProperties.AutomationId="ItemsGridView"
AutomationProperties.Name="Items"
TabIndex="1"
Grid.RowSpan="2"
Padding="116,136,116,46"
ItemsSource="{Binding Source={StaticResource itemsViewSource}}"
ItemTemplate="{StaticResource PatientsItemStyle1}"
SelectionMode="None"
IsSwipeEnabled="false" IsItemClickEnabled="True" ItemClick="ItemsGridView_ItemClick"/>

…
</common:LayoutAwarePage>
[/xml]

Рисунок 9. GridView в XAML-файле PatientsListPage включает прослушиватель событий ItemGsGridView_ItemClick (**)

На рис. 10 показано, что в PatientsListPage.xaml.cs мы реализуем метод ItemsGridView_ItemClick, который вызывает метод Windows Runtime Frame.Navigate() для создания объекта страницы второго уровня PatientGroupItemsPage и отображает ее на экране в качестве текущей страницы. При создании объекта PatientGroupItemsPage мы передаем элемент, получивший щелчок, то есть объект PatientsViewModel.

[cpp]
namespace PRApp
{
/// <summary>
/// A page that displays a collection of item previews.
/// In the Split Application this page
/// is used to display and select one of the available groups.
/// </summary>

public sealed partial class PatientsListPage : PRApp.Common.LayoutAwarePage
{
…
void ItemsGridView_ItemClick(object sender, ItemClickEventArgs e)
{
this.Frame.Navigate(typeof(PatientGroupItemsPage), ((PatientsViewModel)e.ClickedItem));
}
…
}
}
[/cpp]

Рисунок 10. В PatientsListPage.cs реализован прослушиватель событий ItemsGridView_ItemClick (**)

В методе LoadState method в PatientGroupItemsPage.xaml.cs (рис. 11) мы получаем объект пациента из этого параметра и создаем коллекцию Groups для модели данных табличного представления.

[cpp]
/// <summary>

/// Populates the page with content passed during navigation. Any saved state is also

/// provided when recreating a page from a prior session.

/// </summary>

/// <param Title="navigationParameter">The parameter value passed to

/// <see cref="Frame.Navigate(Type, Object)"/> when this page was initially requested.

/// </param>

/// <param Title="pageState">A dictionary of state preserved by this page during an earlier

/// session. This will be null the first time a page is visited.</param>

protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)

{
// TODO: Assign a collection of bindable groups to this.DefaultViewModel["Groups"]

PatientsViewModel patient = (PatientsViewModel)navigationParameter;
this.DefaultViewModel["Groups"] = pgipvm.GetGroups(_patient.id);
}
[/cpp]

Рисунок 11. Метод LoadState в PatientGroupItemsPage.xaml.cs

3 Шаблоны проектов Windows и привязка данных

На рис. 7 и 8 элементы сгруппированы и показаны в удобных табличных представлениях. Шаблоны проектов приложений для магазина Windows в Visual Studio 2012 обеспечивают удобную основу для создания таких страниц пользовательского интерфейса. Готовые шаблоны проектов включают страницу сгруппированных элементов, страницу сведений о группе, страницу сведений об элементе и т. п. В качестве примера мы используем страницу сведений о группе рентгеновских снимков.

В окне обозревателя решений Visual Studio 2012 щелкните имя проекта правой кнопкой мыши и выберите в раскрывающемся меню «Добавить» -> «Создать элемент…». Выберите «Visual C#» в области слева. В середине отображается список готовых шаблонов страниц. Среди этих шаблонов выберите Group Item Page. Область справа предназначена для предварительного просмотра выбранного шаблона. Нужно ввести имя страницы в текстовом поле в нижней части окна (рис. 12) и нажать кнопку «Добавить». Visual Studio 2012 создаст в проекте файлы XRayImagesGroupDetailPage.xaml и XRayImagesGroupDetailPage.xaml.cs.

Рисунок 12. Диалоговое окно добавления нового элемента с шаблонами проектов приложений для магазина Windows (**).

Если изучить созданный файл XRayImagesGroupDetailPage.xaml, мы увидим, что эта страница привязана к контексту данных DefaultViewModel, а элементы табличного представления на этой странице привязаны к Items как к источнику представления коллекции (рис. 13).

[xml]
<common:LayoutAwarePage
x:Name="pageRoot"
x:Class="PRApp.XRayImagesGroupDetailPage"
DataContext="{Binding DefaultViewModel, RelativeSource={RelativeSource Self}}"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:PRApp"
xmlns:common="using:PRApp.Common"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d">
<Page.Resources>

<!-- Collection of items displayed by this page -->
<CollectionViewSource
x:Name="itemsViewSource"
Source="{Binding Items}"/>
</Page.Resources>
…
[/xml]

Рисунок 13. В файле XRayImagesGroupDetailPage.xaml указывается исходный объект привязки данных (**)

В XRayImagesGroupDetailPage.xaml.cs мы видим, что XRayImagesGroupDetailPage происходит от PRApp.Common.LayoutAwarePage (рис. 14).

[cpp]
namespace PRApp

{

/// <summary>

/// A page that displays an overview of a single group, including a preview of the items

/// within the group.

/// </summary>

public sealed partial class XRayImagesGroupDetailPage : PRApp.Common.LayoutAwarePage

{…
[/cpp]

Рисунок 14. XRayImagesGroupDetailPage происходит от LayoutAwarePage

Если в Visual Studio 2012 развернуть папку Common внутри проекта (рис. 15), то мы увидим, что в ней создана группа файлов. Среди этих файлов LayoutAwarePage.cs будет содержать класс, производный от XRayImagesGroupDetailPage.

Рисунок 15. Папка Common в проекте.

Папка Common также содержит файл BindableBase.cs. Модель данных для представления образуется от этого класса. На рис. 16 приводится класс XRayImagesGroupDetailPageViewModel.

[cpp]
…

namespace PRApp.ViewModels
{
public abstract class XRayImageDataCommon : BindableBase
{
}

public class XRayImageDataItem : XRayImageDataCommon
{
}

public class XRayImageDataGroup : XRayImageDataCommon
{
…
private ObservableCollection<XRayImageDataItem> _items = new ObservableCollection<XRayImageDataItem>();
public ObservableCollection<XRayImageDataItem> Items
{
get { return this._items; }
}
…

}

public sealed class XRayImagesGroupDetailPageViewModel
{
…
public static XRayImageDataGroup GetGroup(string uniqueId)
{
…
}
…
}

}
…
[/cpp]

Рисунок 16. XRayImagesGroupDetailPageViewModel.cs: классы группы и элементов, производные от класса BindableBase (**)

Для соединения представления с источниками данных мы в методе LoadState класса XRayImagesGroupDetailPage.xaml передаем производный объект группы и элементов контексту DefaultViewModel (рис. 17).

[cpp]
…
/// <summary>
/// Populates the page with content passed during navigation. Any saved state is also
/// provided when recreating a page from a prior session.
/// </summary>
/// <param name="navigationParameter">The parameter value passed to
/// <see cref="Frame.Navigate(Type, Object)"/> when this page was initially requested.
/// </param>
/// <param name="pageState">A dictionary of state preserved by this page during an earlier
/// session. This will be null the first time a page is visited.</param>
protected override void LoadState(Object navigationParameter, Dictionary<String, Object> pageState)
{
// TODO: Assign a bindable group to this.DefaultViewModel["Group"]
// TODO: Assign a collection of bindable items to this.DefaultViewModel["Items"]
var group = XRayImagesGroupDetailPageViewModel.GetGroup((String) navigationParameter);
this.DefaultViewModel["Group"] = group;
this.DefaultViewModel["Items"] = group.Items;
}
…
[/cpp]

Рисунок 17. В файле XRayImagesGroupDetailPage.cs элементы представления связаны с источником данных в методе LoadState (**)

4 Итоги

В этой статье мы на примере приложения для управления электронными медицинскими картами показали преобразование расширенных функций пользовательского интерфейса приложений iOS в приложение для магазина Windows. В этом примере мы увидели, что в Windows предусмотрен богатый набор функций и средств разработки для создания мощных и удобных пользовательских интерфейсов.

Об авторе

Мяо Вей (Miao Wei) работает инженером по программному обеспечению в отделе корпорации Intel по разработке ПО и обслуживанию. В настоящее время он работает в области масштабирования и внедрения процессоров Intel Atom™. Он обладает более чем 15-летним опытом разработки мобильных платформ. веб-браузеров, приложений и услуг в области геопозицирования, баз данных цифровых карт и других программных продуктов.

*Другие наименования и торговые марки могут быть собственностью третьих лиц.

© Intel Corporation, 2012. Все права защищены.

OpenGL является охраняемым товарным знаком, а OpenGL ES является товарным знаком корпорации Silicon Graphics Inc. Товарные знаки используются с разрешения Khronos.

Загрузить статью

Optimizing Windows* 8 Applications for Connected Standby [Eng., PDF 1.4MB]

Аннотация

В данной статье описывается проверка и анализ поведения приложений Windows 8 * в режиме Connected Standby. Поддержка этого режима является одним из требований Microsoft * WHQL для Windows 8 [1]. Поясняется, как выявить приложения, расходующие слишком много электроэнергии в режиме Connected Standby, и как устранить эту проблему. Этот документ предназначен для разработчиков программного обеспечения, изготовителей оборудования и технических пользователей.

Введение

Режим Connected Standby позволяет системе получать обновления и оставаться на связи при наличии любых сетевых подключений. Этот режим аналогичен принципу работы сотовых телефонов: телефон остается подключенным к сотовой сети, даже если его экран выключен. Подобным образом и приложения Windows 8, поддерживающие режим Connected Standby, запускаются в обновленном состоянии сразу после перехода в активный режим. Дополнительные сведения о режиме Connected Standby на ПК см. на сайте Microsoft [1].

При выключении экрана на всех системах, поддерживающих режим Connected Standby, все запущенные программы (включая и приложения, и ОС) начинают работать в соответствии с новым набором ограничений. Средство Windows Desktop Activity Moderator (DAM) отключает выполнение устаревших приложений, действуя аналогично режиму сна. Для этого выполняется приостановка всех приложений пользовательского сеанса и регулированиевсех сторонних служб. Эти меры позволяют добиться предсказуемого расхода электроэнергии на время бездействия. Это дает возможность системам, поддерживающим режим Connected Standby, свести к минимуму использование ресурсов и долго работать от аккумулятора. При этом приложения Windows 8 смогут поддерживать нужные возможности подключения. Кроме того, при повышении чувствительности аппаратных состояний питания программные службы должны правильно работать, чтобы не пробуждать систему без необходимости, так как при этом будет израсходована дополнительная энергия.

В оставшейся данной статьи описываются средства и методики для понимания поведения системы в режиме Connected Standby. Затем приведены два примера приложений, работу которых в этом режиме можно оптимизировать.

Средства

Мы использовали два широкодоступных средства разработки, чтобы понять поведение приложений в режиме ожидания с подключением.

Windows PowerCfg

Windows PowerCfg — это программа командной строки для управления параметрами электропитания. Эта программа применяет трассировку событий Windows (ETW) для создания профилей систем. Пользователи могут запускать Windows Powercfg для просмотра и изменения планов и параметров электропитания, например времени сна, таймера пробуждения и схем электропитания. Если запустить Powercfg с параметром -energy, будет проведен анализ основных проблем энергоэффективности и работы от аккумулятора: изменения параметров таймеров платформы, изменения таймеров процессами и библиотеками приложений, использование ЦП каждым процессом. При использовании этого параметра также будет проверено, поддерживает ли система режим Connected Standby; будут перечислены параметры управления энергопотреблением оборудования и ОС. Для запуска Windows Powercfg требуются права администратора.

Два параметра командной строки используются для проверки и получения информации о поведении в режиме Connected Standby:

Powercfg –a: Этот параметр выводит все доступные состояния сна системы. Чтобы выполнить эту команду, откройте в Windows командную строку. В командной строке введите: % powercfg –a

Система, поддерживающая режим Connected Standby, сообщит о поддерживаемых состояниях сна, одним из которых будет этот режим. На рис. 1 показаны выходные данные команды powercfg –a для системы, поддерживающей режим Connected Standby.

Рисунок 1. Powercfg -a output

Powercfg -batteryreport

Параметр -batteryreport предоставляет информацию о поддержке режима Connected Standby и другие связанные данные. Создается отчет (в формате HTML) о статистике работы системы от аккумулятора путем сбора профиля на основе постоянно запущенной встроенной трассировки системы. Этот отчет содержит сводные данные об установленном аккумуляторе, версии BIOS, поддержке режима Connected Standby, а также о сроке работы от аккумулятора на основе фактического использования системы. На рис. 2 показан пример выходных данных команды с параметром -batteryreport, если ПК поддерживает режим Connected Standby.

Рисунок 2. Отчет о состоянии аккумулятора с поддержкой режима Connected Standby

В отчете также указывается использование аккумулятора в активном состоянии, в приостановленном состоянии и в режиме Connected Standby, как показано на рис. 3.

Рисунок 3. Использование аккумулятора в различных состояниях

Дополнительные сведения о решении Windows Powercfg см. на Microsoft website [2].

Microsoft Windows Performance Analyzer

Средство Windows Performance Analyzer (WPA), также известное под названием xperf, представляет собой набор инструментов мониторинга для составления подробных профилей производительности и электропитания Microsoft Windows и приложений. WPA удобно использовать для устранения проблем с утечкой энергии.

Перед переходом к примерам давайте разберемся с терминологией WPA. Вот определения основных терминов и названий столбцов WPA, взятые из документации System Internals, находящейся по адресу [3]:

• Ready Thread:поток в готовом состоянии, ожидающий выполнения или готовый к переключению после завершения ожидания. При поиске потоков для выполнения диспетчер рассматривает только пул потоков в готовом состоянии.
• Standby: поток в ждущем режиме, выбранный для последующего запуска на определенном процессоре. При возникновении подходящих условий диспетчер выполняет переключение контекста к этому потоку. Только один поток может быть в ждущем режиме для каждого процессора в системе. Обратите внимание, что поток может быть выгружен из ждущего состояния еще перед выполнением (например, если поток с более высоким приоритетом запускается перед началом выполнения ждущего потока).
• Waiting: поток может перейти в состояние ожидания несколькими способами: поток может дожидаться, пока будет выполнена синхронизация объекта; операционная система может ждать от имени потока (например, при операции ввода-вывода); подсистема среды может дать команду потоку на приостановку. Когда состояние ожидания потока завершается, то, в зависимости от приоритета, поток либо начинает выполняться сразу же, либо возвращается в состояние готовности.
• CPU Precise:график CPU Usage (Precise) содержит информацию, связанную с событиями переключения контекста. Каждая строка соответствует набору данных, связанному с одним переключателем контекста при начале выполнения потока.
• % CPU Usage: использование ЦП новым потоком после его включения выражается в виде процента общего времени ЦП в отображаемом диапазоне времени.
• Count: количество переключателей контекста в строке (всегда 1 для одиночных строк).
• NewThreadId: идентификатор нового потока.
• NewThreadStack: стек нового потока после его подключения.
• ReadyingProcess: процесс, владеющий готовым потоком.
• SwitchInTime(s): время переключения в новый поток.
• LastSwitchOutTime (s): время последнего переключения из нового потока.
• TimeSinceLast (s): SwitchInTime(s) - LastSwitchOutTime (s)

На рис. 4 показаны имена столбцов в пользовательском интерфейсе WPA.

Рисунок 4. Общий вид WPA

Generic Events:предоставленные пользователем события заполняются для анализа данных трассировки ядра.

• OneShotTimer : может входить в состав всегда включенного таймера в режиме ожидания с подключением. Операционная система запускает OneShotTimer через каждые 30 секунд. Приложения могут создавать таймер, вызывая SetTimer или SetEvent.
• PeriodicTimer: эти таймеры срабатывают после истечения указанного времени, а затем сбрасываются в исходное состояние.

Периодические таймеры работают на уровне приложений и могут запускать переходы режима ядра. Однократные таймеры работают на уровне операционной системы в режиме Connected Standby.

Разработчики должны выполнять не менее двух тестов: базовый (без приложений) и целевой (с установленным приложением), чтобы выделить влияние приложения.

Сбор данных трассировки

• Выполните команду powercfg.exe –a, чтобы убедиться, что система поддерживает режим Connected Standby.
• Установите Windows Performance Analyzer из Windows ADK [4].
• Запустите сбор данных трассировки, создав пакетный файл со следующей командной строкой:
  • xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+CSWITCH+IDLE_STATES+POWER+TIMER+CLOCKINT+IPI+DISPATCHER+DISK_IO -stackwalk TimerSetPeriodic+TimerSetOneShot -clocktype perfcounter -buffering -buffersize 1024 -MinBuffers 128 -MaxBuffers 128

• PROC_THREAD+LOADER: предоставляет информацию о прерываниях устройства и таймере.
• INTERRUPT: используется для анализа событий прерывания. Предоставляет информацию, связанную с аппаратными прерываниями.
• DPC: используется для анализа источников прерывания. Предоставляет информацию, связанную с журналами DPC.
• CSWITCH: используется для анализа источников прерывания. Предоставляет информацию, связанную с переключателями контекста.
• IPI: предоставляет информацию, связанную с прерываниями между процессорами.
• TimerSetPeriodic+TimerSetOneShot: Required требуемые стеки для анализа таймера и анализа прерываний устройства.
• Дайте системе войти в состояние Connected Standby (например, нажав кнопку питания)
  • Подождите, пока средство xperf соберет данные трассировки в течение не менее 4 часов. При большей длительности трассировки можно лучше изучить действия программного обеспечения в режиме Connected Standby.
  • Пробудите систему из состояния Connected Standby (например, нажав кнопку питания).

• Остановите трассировку.

xperf -flush xperf -stop xperf -merge \kernel.etl MyTrace.etl

После завершения трассировки в текущей папке будет создан файл Mytrace.etl.

Постобработка трассировки

Выполните следующую команду для постобработки файла трассировки с информацией о пробуждении:

xperf -symbols -i mytrace1.etl -o cleanCS_diag.csv -a energydiag –verbose

Можно обработать определенную область трассировки, указав диапазон

Xperf –symbols –I mytrace1.etl –o cleanCS_diag.csv –a energygdiag –range T1 T2

Например: xperf -symbols -i -o EnergyDiag.csv -a energydiag -verbose -range 1000000 15000000000

На рис. 5 показаны файлы, созданные после постобработки.

cleanCS_diag: содержит все события и действие пробуждения системы.

MyTrace1: содержит необработанную информацию о трассировке.

Рисунок 5. Пример выходных данных трассировки

cleanCS_diag:

При постобработке собранных данных трассировки формируется журнал, содержащий количество прерываний устройств, такт таймеров и результаты для каждого ЦП. Также указывается частота устройства и действия пробуждения таймера. Постобработку также можно выполнить для данных трассировки, полученных в режиме простоя и при активной работе. Постобработка сценария помогает определить влияние работы программного обеспечения на расход электроэнергии.

Рисунок 6. Выходные данные сценария постобработки

Общее число прерываний устройства (рис. 6) является суммой количества прерываний всех модулей устройства в собранных данных трассировки. Суммарное истечение таймеров — подмножество прерываний, вызванных срабатываниями таймеров. В режиме ожидания с подключением истечение таймеров включает системные таймеры, события, а также oneshottimer и periodictimer, связанные с регулировкой.

Теперь следует понять, чем занимается система в режиме Connected Standby. Можно прокрутить отчет вниз до схемы Busy Enter/Exit Time, на которой нужно найти группу All CPUs. Значение Busy Percent позволяет точно оценить деятельность системы в режиме Connected Standby. Это дает возможность понять, насколько занята система. Чем выше показатель занятости по отношению к базовому значению, тем сильнее влияние на потребление электроэнергии. На рис. 7 показана трассировка базового значения занятости без тестовых приложений. На рис. 8 показана трассировка с несколькими запущенными приложениями и фоновой службой. Сравнение рисунков 7 и 8 показывает повышение занятости в 150 раз из-за пробуждений, вызванных приложениями, и фоновой службы.

Рисунок 7. Базовые выходные данные

Рисунок 8. Выходные данные трассировки с установленными приложениями

Анализ необработанных данных трассировки:

Также можно изучить файл трассировки непосредственно в Windows Performance Analyzer. На рис. 9 показано средство Graph Explorer в составе WPA.

Рисунок 9. Окно WPA после открытия файла трассировки

На рис. 10 показаны данные вычислений на вкладке анализа. Можно приблизить полоски действий, чтобы увидеть действия пробуждения процессов и системы. На рис. 10 показано, каким образом таймер OneShotTimer системы согласуется с действиями процессов.

Рисунок 10. Общее представление системы в режиме Connected Standby

Чтобы проверить вызовы OneShotTimer из системы, перетащите события из группы действий системы в окно анализа. Загрузить символы можно с сервера Майкрософт или из папки символов приложения, выбрав команду Load Symbols в меню Trace. На рис. 11 показан этот элемент в меню Trace.

Рисунок 11. Загрузка символов

В WPA можно включить график и таблицу для анализа стека и декодирования процессов и потоков, щелкнув первый элемент в правом верхнем углу графика WPA, как показано на рис. 12.

Рисунок 12. График и таблица WPA

Теперь следует включить столбцы, как показано на рис. 12, чтобы проанализировать работу стека OneShotTimer.

Расположите столбцы таблицы анализа, чтобы найти действия пробуждения, запущенные системой или службами приложений. На рис. 13 показан процесс System с идентификатором потока 68, запускающий таймер OneShotTimer 36 раз в течение отображаемого отрезка времени. Пробуждение запускается системным процессом через каждые 30 секунд.

Рисунок 13. Работа стека таймера OneShotTimer в WPA

«Хорошее» и «плохое» поведение:

При оптимизации приложений для снижения потребления электроэнергии важно понимать разницу между «хорошим» и «плохим» поведением. Такие действия как доступ к хранилищу или доступ обновлений программного обеспечения к сети могут пробудить систему, если будут запущены вне системного пробуждения.

Хорошее поведение: служба приложения выполняется внутри процесса System. Т. е. служба приложения переходит в состояния сна до того, как процесс System перейдет в состояние сна. Такой подход помогает выполнить требование WHQL для режима Connected Standby в Microsoft Windows 8: в течение 16 часов ожидания с подключением может быть израсходовано не более 5 % заряда аккумулятора.

Плохое поведение: приложение работает независимо от процесса System или входит в состояние сна после того, как процесс System переходит в состояние сна. Несогласованные пробуждения могут вызвать излишний расход электроэнергии в режиме Connected Standby, из-за чего выполнить требование Microsoft WHQL будет невозможно.

На рис. 14 показано «хорошее» и «плохое» поведение в режиме ожидания с подключением.

Рисунок 14. «Хорошее» и «плохое» поведение в режиме Connected Standby

Пример 1. Доступ к хранилищу.

В программных службах, например в антивирусах и службах обновления программного обеспечения, широко распространен доступ к локальному хранилищу. Когда эти службы запущены в режиме Connected Standby, доступ к локальному хранилищу должен быть отложен до пробуждения процесса System. На рис. 15 показан сценарий доступа к хранилищу в течение примерно 65 секунд в режиме Connected Standby. Приложение пробуждается, когда процесс System (выделен оранжевым), переходит в активное состояние сна. ProcessX.exe запускает доступ к хранилищу в System32, из-за чего система не может перейти в режим Connected Standby. Можно оптимизировать приложение, исключив длительный доступ к хранилищу. Если приложению нужен доступ к хранилищу в режиме ожидания с подключением, можно объединить работу приложения с работой системы и перейти в состояние ожидания путем широковещательного уведомления об изменении состояния электропитания.

Рисунок 15. Доступ службы приложения к хранилищу в режиме Connected Standby

После этого изменения процесс доступа к хранилищу и процесс System будут объединены в режиме Connected Standby (см. рис. 16). Это пример хорошего поведения: приложение не влияет на энергопотребление системы.

Рисунок 16. Оптимизированный доступ к хранилищу в режиме Connected Standby

Пример 2. Пробуждение потоков приложения.

Оптимизация пробуждения приложения, вызванного ОС, — непростая задача. Необходимо понимать события ЦП Precise и Generic, чтобы узнать, происходит ли OneShotTimer при пробуждении процесса System. На рис. 16 показано пробуждение потоком приложения, когда процесс System находится в состоянии сна. Это образец неправильного написания служб процессов, которые без необходимости поддерживают систему в пробужденном состоянии. ProcessX.exe (ID: 2440) создает несколько потоков. В таблице на рис. 16 видны два потока, не согласованных с процессом System. Используя общую таблицу событий, можно сопоставить идентификатор потока с setTimer и прерываниями часов. Как показано на рис. 16, существуют задачи потока Timer Set, которые следует рассмотреть (идентификаторы потоков 3432 и 1824). Теперь следует сопоставить идентификатор потока, полученный на предыдущем шаге (Thread ID 3432 и Thread ID 1824) с таблицей CPU Usage (Precise), чтобы найти деятельность, связанную с этими потоками. Деятельность может быть связана с Timer Set, с расписанием потоков или с действиями ввода-вывода. Для наглядного отображения можно построить несколько графиков в одном представлении.

Рисунок 17. Потоки приложений поддерживают систему активной в состоянии сна

Функцию SetTimer можно использовать для изменения таймера потока в приложении.

UINT_PTR WINAPI SetTimer(
  _In_opt_  HWND hWnd,
  _In_      UINT_PTR nIDEvent,
  _In_      UINT uElapse,
  _In_opt_  TIMERPROC lpTimerFunc
);

Окно приложения (HWND) используется для обработки уведомлений посредством процедуры window, которую следует вызвать через количество микросекунд, заданное значением uElapse, даже после перехода процесса System в режим Connected Standby.

Если в приложении есть окно (HWND) и нужно обрабатывать эти уведомления посредством процедуры window, чтобы это исправить, вызовите RegisterSuspendResumeNotification для регистрации этих сообщений (или UnregisterSuspendResumeNotification для отмены регистрации). Можно использовать DEVICE_NOTIFY_WINDOW_HANDLE в параметре Flags и передавать значение окна HWND в параметре Recipient. Получено сообщение WM_POWERBROADCAST.

Если приложение не имеет обработчика HWND или если нужен прямой обратный вызов, вызовите PowerRegisterSuspendResumeNotification для регистрации на эти сообщения (или PowerUnregisterSuspendResumeNotification для отмены регистрации). Можно использовать DEVICE_NOTIFY_WINDOW_HANDLE в параметре Flags и передавать значение типа PDEVICE_NOTIFY_SUBSCRIBE_PARAMETERS в параметре Recipient.

Заключение

Реализация режима ожидания с подключением в приложениях крайне важна для продления времени работы от аккумулятора. Системы, поддерживающие режим Connected Standby, должны отвечать требованиям сертификации оборудования Windows Hardware Certification (WHCK) в отношении потребления электроэнергии. Согласно этим требованиям, все системы в режиме Connected Standby должны израсходовать не более 5 % заряда аккумулятора в течение 16-часового периода бездействия в фабричной конфигурации по умолчанию. Сертификационный тест находится на сайте Microsoft WHCK.

Об авторе

Мануж Сабарвал (Manuj Sabharwal) работает инженером по программному обеспечению в отделе Software Solutions Group корпорации Intel. Мануж изучает возможные способы повышения эффективности расхода электроэнергии программами в активном состоянии и в состоянии простоя. Он обладает высокой научно-технической квалификацией в области эффективности расхода электроэнергии; им разработан ряд учебных и технических справочников, применяющихся в данной отрасли. Также он работает над поддержкой клиентских платформ путем оптимизации программного обеспечения.

Справочные материалы

[1] Microsoft WHCK: http://msdn.microsoft.com/en-US/library/windows/hardware/jj128256

[2] PowerCfg: http://technet.microsoft.com/en-us/library/cc748940(WS.10).aspx

[3] Windows Internals: http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx

[4] Windows Assessment Toolkit: http://www.microsoft.com/en-us/download/details.aspx?id=30652

*Другие наименования и торговые марки могут быть собственностью третьих лиц.

Copyright ©2013 Intel Corporation.

By Steve Hughes

Загрузка

Adding Multi-Touch Support to Unity* Games on Microsoft Windows* 7 and Windows* 8 Desktop [Eng., PDF 299.45 KB]
Check1.cs [ZIP 3.52 KB]
DLLMain.cpp [ZIP 8.21 KB]

Аннотация

В настоящее время Unity не обрабатывает сообщения касания в приложениях, работающих под управлением Windows 7 и классического интерфейса Windows 8. Мы предлагаем решение, с помощью которого разработчики могут получить доступ к доступным событиям мультисенсорного ввода в приложениях Unity, работающих под управлением Windows. Это решение выполнено в виде подключаемого модуля, использующего различные API-интерфейсы Windows для перехвата сообщений касания, отправляемых приложению. Мы обрабатываем информацию из этих сообщений касания, а затем создаем простой набор данных, доступ к которому возможен с помощью C# из сценария в приложении Unity.

1. Обработка сообщений касания в Windows

Процесс обработки сообщений касания хорошо задокументирован в сети MSDN и в других местах, но мы упомянем определенные моменты, имеющие отношение к обсуждаемому вопросу. WNDPROC активного окна получает сообщение WM_TOUCH, когда происходит событие касания. После получения сообщения приложение вызывает GetTouchInputInfo() для заполнения массива структур PTOUCHINPUT по одной для каждой точки касания на поверхности. Нижнее слово параметра wParam, переданного WNDPROC, содержит количество записей PTOUCHINPUT в массиве.

В этом случае нас особо интересует член dwID структур PTOUCHINPUT. Этот идентификатор связывает определенную запись PTOUCHINPUT с записями, предоставленными прежним вызовам GetTouchInputInfo(). Это обеспечивает временную продолжительность точки касания. Многие приложения пытаются найти предыдущую точку касания как можно ближе к новой точке и предполагают, что они совпадают. Это не всегда верно. Например, множество касаний могут приходиться близко друг от друга или пересекаться друг с другом на экране.

Данные касания можно связать с информацией о точке касания после ее получения из прежних вызовов GetTouchInputInfo(). После этого данные соответственным образом обрабатываются приложением. В приложениях Unity требуются дополнительные действия для образования информации о касаниях в сценариях C#, управляющих работой приложения.

2. Использование подключаемых модулей в Unity

Подключаемые модули Unity компилируются в виде DLL-библиотек, механизм экспорта хорошо задокументирован. «Экспортированные функции» остаются такими же в подключаемых модулях Unity, какими они являются в любых других DLL-библиотеках. Подключаемый модуль может быть написан на любом языке, если компилятор способен создать выходной файл DLL, а экспортированные функции всегда можно вызвать из сценария C# в Unity.

Экспортированные функции можно вызвать напрямую из сценария C# после загрузки подключаемого модуля Unity. В C# для доступа к экспортированным функциям достаточно просто объявить их в сценарии C# как extern. Например, предположим, что экспортированная функция из DLL-библиотеки C++ с именем MyPlugin имеет следующий заголовок:

__declspec(dllexport) int __cdecl Init(int p);

Для доступа к ней из C# объявим ссылку типа extern на нее.

[dllimport (“MyPlugin”)] private static extern int Init(int p);

Затем вызовем функцию Init (int) в сценарии.

3. Реализация интерфейса касаний с помощью подключаемого модуля

Для успешного получения сообщений касания Windows, направленных для приложения Unity, нужно выполнить несколько действий. Сначала мы опишем действия, а затем завершим процесс с помощью комментариев в исходном коде.

Процедура настройки для подключаемого модуля включает присоединение обработчика с помощью SetWindowsHookEx() для получения сообщений WM_TOUCH для приложения Unity. Для этого требуются две вещи: дескриптор модуля DLL и идентификатор потока, создавшего окно Unity, имеющее фокус. Для получения идентификатора потока, создавшего окно Unity, нужно сначала найти его дескриптор. Запись DLLMain() в DLL покажет дескриптор модуля. Самый простой способ найти дескриптор окна Unity — передать имя окна Unity из C# в подключаемый модуль, а затем перечислить все окна рабочего стола в подключаемом модуле с помощью EnumDesktopWindows(), чтобы найти дескриптор. Когда окно будет найдено, можно получить его дескриптор. Имея дескриптор окна, вызовите GetWindowThreadProcessID() для получения идентификатора потока, необходимого для вызова SetWindowsHookEx().

В коде видно, что SetWindowsHookEx() вызывается дважды; установлено два обработчика: один присоединен к WH_GETMESSAGE, другой к WH_CALLWNDPROC. Дело в том, что сообщения WN_TOUCH прибывают в WNDPROC в Windows 7 не так, как в Windows 8. В Windows 7 сообщения публикуются в очередь. В Windows 8 они напрямую вставляются в WNDPROC. Не забудьте высвободить обработчики Windows по завершении работы, поскольку они являются ограниченным ресурсом в ОС.

AПо умолчанию приложения не поддерживают касания. Чтобы приложение Unity могло получать сообщения касаний, подключаемый модуль должен вызвать RegisterTouchWindow(), чтобы включить эти сообщения. Для этого вызова потребуется предварительно получить обработчик окон.

По завершении наши обратные вызовы будут вызываться всякий раз при отправке сообщений окну Unity. Остается всего лишь отслеживать сообщения касания, а остальные сообщения возвращать в Unity.

4. Обработка данных касания

Для доступа к данным касания, полученным из подключаемого модуля, предусмотрены две экспортированные функции. Их можно изменить, если целесообразнее использовать другой интерфейс. Давайте уточним, как происходит использование данных.

Int GetTouchPointCount() возвращает целое число, представляющее количество контактных точек, активных в данный момент на экране.

Void GetTouchPoint(int ID, tTouchData Data) возвращает активную точку касания с идентификатором индекса из подключаемого модуля.

Как мы упомянули выше, для данных, предоставляемых вызовом метода GetTouchPoint(), требуется точность для поддержания временной согласованности при обработке точек касания в Unity. Подключаемый модуль поддерживает внутренний список активных точек и старается соблюдать идентификаторы, назначенные операционной системой Windows. Идентификаторы Windows не совпадают с идентификатором, предоставленным экспортированной функции GetTouchPoint(). Опросите структуру tTouchData для выяснения фактического идентификатора точки касания, чтобы поддерживать временную целостность между кадрами.

5. Заключение

Хотя движок Unity сам по себе не обрабатывает сообщения касания в приложениях для Windows 7 и классического интерфейса Windows 8, можно зарегистрировать окно Unity для получения касаний от подключаемого модуля. После регистрации окна определенные приемы предоставляют нам доступ к сообщениям касания в сценарии приложения Unity. Многие разработчики ценят Unity, поскольку это интуитивно понятное и гибкое средство, позволяющее быстро разрабатывать весьма привлекательные и мощные игры. Доступ к сенсорному вводу в Unity значительно расширит ваши возможности по созданию динамичных игр и приложений мультимедиа для современных сенсорных устройств под управлением Windows.

Ресурсы

• Главная страница MSDN: http://msdn.microsoft.com/en-US/
• Исходный код подключаемого модуля и пример проекта: http://software.intel.com/en-us/blogs/2013/05/01/the-unity-multi-touch-source-finally

Intel и эмблема Intel являются товарными знаками корпорации Intel в США и в других странах.
© Intel Corporation, 2013. Все права защищены.
*Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

Cкачать статью

Скачать Handling touch input in Windows* 8 Applications [Eng., PDF 745KB]

Поскольку все больше устройств поддерживает сенсорный ввод, обработка сенсорных методов взаимодействия в приложениях становится все более важной.

Стандартные элементы управления и шаблоны Windows* 8 идеально обрабатывают сенсорный ввод,поэтому, если вы пользуетесь только ими, вам нет необходимости разбираться в технических подробностях.

Если же вы работаете с классическим приложением или хотите разработать собственные элементы управления (например, для игры), то вы должны знать, как правильно обрабатывать сенсорный ввод.

При этом приложения, которые работали под управлением Windows 7, продолжат работать:

• Если ваше приложение обрабатывает только события мыши, то события касания будут сведены к ним (не будет только события наведения указателя мыши).
• Если ваше приложение использует события касания Windows 7 (API-интерфейсы WM_TOUCH/WM_GESTURE), то все в порядке, эти API по-прежнему доступны.

В обоих случаях можно подумать над доработкой приложения с использованием новых API ввода Windows 8, поскольку они помогут обеспечить однородность с другими приложениями и в целом повысить удобство для пользователей.

Если ваше приложение изначально не было предназначено для обработки сенсорного ввода, вам также может потребоваться доработать пользовательский интерфейс, чтобы сделать его более пригодным для сенсорного управления: увеличить размер элементов управления, убрать лишние элементы и т. п. Советы по проектированию интерфейсов для сенсорного управления см. здесь: Designing for Ultrabook™ Devices and Touch-enabled Desktop Applications

Разработка для сенсорного управления без сенсорного устройства

Если у вас нет сенсорных устройств, можно опробовать ваше классическое приложение или приложение для Магазина Windows в имитаторе Windows 8, который входит в состав Visual Studio* 2012 на платформе Windows 8.

Эта программа находится в папке C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Simulator\11.0\Microsoft.Windows.Simulator.exe.

В нем можно запускать любое приложение, как в обычном сеансе работы:

Приложения для Магазина Windows 8 также можно запускать напрямую в имитаторе из Visual Studio:

Затем в правой части окна имитатора можно выбрать режим взаимодействия по умолчанию. По умолчанию используется мышь, но нас интересуют три других режима: одиночное касание, сведение для масштабирования и режимы вращения.

Для режимов двойного касания используется щелчок левой кнопкой мыши и колесико мыши для масштабирования или поворота.

Сенсорное взаимодействие в Windows 8

Чтобы ваше приложение было удобным для пользователей, используемые в нем жесты должны совпадать со стандартными жестами в ОС:

Источник: //build/ 2011 - APP-391T

Принцип ввода указателя

Общие сведения

Обработка в приложениях сразу нескольких методов ввода может сильно все усложнить. К счастью, в Windows 8 корпорация Microsoft внедрила объединенный ввод с помощью элемента Pointer (Указатель):

Метод ввода Pointer объединяет методы ввода мышью, пером и касаниями и является абстракцией этих методов ввода. Кодирование для указателей дает возможность обрабатывать все эти методы ввода, написав код всего один раз.

События указателя — самое простое, с чем вы столкнетесь. Вы можете получить их для любого элемента пользовательского интерфейса Windows 8 XAML, а также для ICoreWindow. Со стороны HTML5 эти элементы доступны, но их имена несколько отличаются. Они имеют префикс MS: MSPointerDown, MSPointerMove, MSPointerUp.

Эквивалентами событий указателя в Win32* являются сообщения WM_POINTERXXX, которые можно получать в функции обратного вызова окна Win32. По умолчанию в приложениях Win32 сообщения WM_POINTERXXX не включают сообщения мыши. Чтобы получать действительно объединенные сообщения указателя, нужно сначала вызвать EnableMouseInPointer(true).

События указателя (XAML / JS / Win32)

• PointerPressed / MSPointerDown / WM_POINTERDOWN
• PointerMoved / MSPointerMove / WM_POINTERUPDATE
• PointerReleased / MSPointerUp / WM_POINTERUP
• PointerEntered / MSPointerHover / WM_POINTERENTER: начато состояние наведения указателя.
• PointerExited / MSPointerOut / WM_POINTERLEAVE: завершено состояние наведения указателя.
• PointerCanceled / MSPointerCancel /: потеря указателя (касание отменено подключением пера, слишком много контактов, пользователь вышел из системы...).
• PointerCaptureLost / MSLostPointerCapture / WM_POINTERCAPTURECHANGED
• PointerWheelChanged / - / WM_POINTER(H)WHEEL:  состояние обычного или горизонтального колесика прокрутки изменено по крайней мере на одну ступень после последнего события.

Объекты более высокого уровня, такие как элементы пользовательского интерфейса XAML, предоставляют события жестов и манипуляций напрямую:

События жестов

• Tapped
• DoubleTapped
• RightTapped: длительное касание, равноценное щелчку правой кнопкой мыши.
• Holding / MSGestureHold: срабатывает перед высвобождением указателя.

События манипуляции

• ManipulationStarting
• ManipulationStarted
• ManipulationDelta
• ManipulationCompleted
• ManipulationInertiaStarting

События манипуляции также могут предоставлять информацию о масштабировании, повороте и прокрутке. Кроме того, они предоставляют данные инерции. Их можно настроить с помощью ManipulationModeдля переключения инерции. Можно разрешить только определенные виды взаимодействия/добавить ограничения (например, направляющие для преобразования в движение по осям X/Y).

В приложениях для Магазина Windows Windows 8, написанных на HTML5/JavaScript*, можно использовать метод WinRT GestureRecognizerдля доступа к этим событиям.

Если приложение также должно работать в IE10 (т. е. без WinJS), можно использовать объект MSGesture. Он будет переключать следующие события, равноценные событиям манипуляции: MSGestureStart, MSGestureEnd, MSInertiaStart и MSManipulationStateChanged, а также следующим событиям жестов: MSGestureTap, MSGestureHold.

Примечание. События манипуляции также доступны для классических приложений C#/WPF 4.x в том виде, как они работали под управлением Windows 7, без ManipulationMode.

Обзор API-интерфейсов Windows 8

Если объект, с которым вы работаете, не переключает события жестов, можно отправить события указателя интерфейсу GestureRecognizer. GestureRecognizer переключит выбранные события жестов и манипуляций, а также события перетаскивания и поперечной прокрутки.

InteractionContext в Win32 является эквивалентом GestureRecognizer в API Windows Runtime. Объект Interaction Contextпереключает INTERACTION_CONTEXT_OUTPUT_CALLBACK, связанный с другими жестами и манипуляциями.

Кроме того, в сенсорное приложение можно встроить интерфейс InkRecognizer. Он позволяет распознавать рукописный ввод в классических приложениях и в приложениях для Магазина Windows 8.

Также можно внедрять события касания из классических приложений с помощью API Touch Injection API.

Сводка по способам интеграции возможностей сенсорного управления в приложения

Вот краткая сводка по способам обработки сенсорного ввода в зависимости от объектов и типов приложений, с которыми вы работаете:

Образцы кода

Win32* touch/Interaction Context sample – Intel

Windows* 8 gestures C#/JS sample – MSDN

DirectX* Touch input C++ sample – MSDN

InkRecognizer JS sample – MSDN

Intel, эмблема Intel и Ultrabook являются товарными знаками корпорации Intel в США и в других странах.

© Intel Corporation, 2012. Все права защищены.

*Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

Загрузить PDF [Eng]

Почему устройства 2 в 1?

Устройство 2 в 1— это компьютер, который может быть как ноутбуком, так и планшетом. В режиме ноутбука (настольном режиме) основными устройствами ввода являются клавиатура и мышь. В режиме планшета для ввода используется сенсорный экран, то есть применяется касание пальцами или пером. Устройство 2 в 1, как и ультрабук Intel®, обеспечивает точность и управляемость при использовании любых методов ввода: можно печатать на клавиатуре при работе, или управлять касаниями в играх.

Разработчикам приходится рассматривать разные сценарии в своих приложениях, чтобы использовать преимущества нового типа устройств. У некоторых приложений в обоих режимах можно сохранить одинаковое меню и внешний вид. В других программах, таких как Krita Gemini для Windows* 8, функции и элементы интерфейса в разных режимах будут различаться. Krita — это программа для создания набросков и рисования. Это полнофункциональное решение для создания цифровых изображений с нуля. В этой статье описывается, как разработчики Krita реализовали определение режима устройства 2 в 1, включая автоматическое переключение режима и переключение режима пользователем. Кроме того, рассматриваются определенные области, о которых разработчикам следует позаботиться при реализации приложений 2 в 1.

Введение

В ходе многолетнего развития компьютерной техники применялись самые разные методы ввода, от перфокарт и командной строки до указателей, таких как мышь. С появлением сенсорных экранов для выбора объектов на экране можно использовать не только мышь, но также пальцы и перо. В большинстве случаев далеко не все задачи удобно выполнять с сенсорным управлением, но в приложениях с возможность выбора метода ввода, таких как Krita Gemini, в этом и нет нужды. Устройства 2 в 1 позволяют выбрать наиболее удобный режим пользовательского интерфейса на одном устройстве.

Устройство 2 в 1 может переводиться из режима ноутбука в режим планшета и обратно разными способами (Рис. 1 и Рис. 2). Множество примеров доступно на сайте Intel. Устройство можно перевести в режим планшета из режима ноутбука, отсоединив экран от клавиатуры либо отключив клавиатуру и сделав экран основным устройством ввода (например, сложив экран поверх клавиатуры). Производители компьютеров предоставляют информацию о смене режима работы оборудования операционной системе. Событие API Windows* 8 WM_SETTINGCHANGE и текстовый параметр ConvertibleSlateModeсигнализируют об автоматическом переключении в режим планшета и обратно в режим ноутбука. Кроме того, разработчикам рекомендуется для удобства пользователей добавить и кнопку, чтобы можно было переключать режимы вручную.

Устройства 2 в 1 могут переключаться между режимами планшета и ноутбука разными способами; аналогично можно создать и программу таким образом, чтобы она разными способами реагировала на переключение режимов. В некоторых случаях в режиме планшета следует сохранить пользовательский интерфейс как можно более близким к режиму ноутбука; в других случаях можно внести довольно существенные изменения. Корпорация Intel сотрудничает со многими поставщиками, чтобы помочь им реализовать разные режимы работы трансформеров в своих приложениях. Специалисты Intel помогли разработчикам KO GmBH объединить функциональность приложения Krita Touch с популярным приложением для рисования с открытым исходным кодом Krita (для ноутбука) в новом приложении Krita Gemini. Над проектом Krita работает активное сообщество разработчиков, приветствующее новые идеи и предоставляющее высококачественную поддержку. Команда добавила механизмы для гладкого преобразования из режима ноутбука (мышь и клавиатура) в сенсорный интерфейс в режиме планшета. См. преобразование пользовательского интерфейса Krita Gemini в кратком видеоролике на Рис. 3.

Рисунок 3. Видео Преобразование пользовательского интерфейса Krita Gemini UI,щелкните значок для запуска

Intel сотрудничает со множеством производителей ПК, чтобы развивать направление 2 в 1. Intel Developer Zone предоставляет различные ресурсы, чтобы помочь разработчикам в создании приложений. Смотрите раздел Дополнительные ресурсы в конце статьи.

Создание в режиме планшета, улучшение в режиме ноутбука

Разработчики Gemini постарались максимально использовать все возможности интерфейса в обоих режимах работы. На Рис. 4 и Рис. 5 видно, что пользовательский интерфейс в двух режимах отличается очень сильно. Это дает пользователю возможность плавно перейти от рисования «в поле» в режиме планшета к ретушированию и проработке более тонких деталей в режиме ноутбука.

Рисунок 4: Пользовательский интерфейс Krita Gemini в режиме планшета

Рисунок 5: Пользовательский интерфейс Krita Gemini в режиме ноутбука

Существует три основных этапа для реализации в приложении поддержки переключения между двумя режимами работы.

Этап 1 — Поддержка сенсорного управления.Нам повезло: поддержка сенсорного вводаполучила широкое распространение до появления устройств 2 в 1. Обычно для реализации этого механизма требуется значительно больше усилий, чем для переключения между режимами планшета и ноутбука. Корпорация Intel опубликовала статьи о добавлении поддержки сенсорного интерфейса в приложениях для Windows 8.

Этап 2 — Поддержка переключения режимов. В первой части видеоролика (Рис. 3) показана автоматическая смена режима на основе срабатывания датчика; в данном случае это поворот (Рис. 6). После этого показана смена режима при нажатии пользователем соответствующей кнопки в приложении (Рис. 7).

Рисунок 6:Переключение приложения по срабатыванию датчика при смене режима

Рисунок 7:Кнопка переключения Switch to Sketch — переключение в режим планшета запускается пользователем

Для автоматического переключения требуется определить состояние датчика, отслеживать его и выполнять соответствующие действия при известном состоянии. Кроме того, для удобства пользователей следует добавить и возможность переключать режимы работы приложения вручную. Пример добавления смены режима на основе датчика можно найти в статье Intel «How to Write a 2 in 1 Aware Application». Код приложения Krita для управления переключениями между режимами можно найти в исходном коде этого приложения, выполнив поиск по слову SlateMode. Программа Krita распространяется на условиях лицензии GNU Public License. Для получения последней информации см. репозиторий исходного кода.

// Snip from Gemini - Define 2-in1 mode hardware states:

#ifdef Q_OS_WIN
#include <shellapi.h>
#define SM_CONVERTIBLESLATEMODE 0x2003
#define SM_SYSTEMDOCKED 0x2004
#endif

Не все компьютеры с сенсорным управлением поддерживают автоматическое переключение, поэтому мы рекомендуем поступить так, как сделали разработчики Krita Gemini, и добавить в приложение кнопку, с помощью которой пользователи могли бы вручную переключать режимы работы приложения. Кнопка Gemini показана на Рис. 7. Смена пользовательского интерфейса по нажатию кнопки происходит так же, как при срабатывании механического датчика. Информация на экране и устройство ввода по умолчанию изменятся с сенсорного экрана и крупных значков в режиме планшета на клавиатуру, мышь и мелкие значки в режиме ноутбука. Тем не менее, поскольку датчик не срабатывал, метод, использующий кнопку, должен сменять параметры экрана, значков и устройства ввода по умолчанию без получения данных о состоянии датчика. Поэтому разработчики должны предоставить пользователю возможность переключения между режимами мышью или касанием вне зависимости от состояния кнопки, если пользователь вдруг выберет не тот режим, который ему нужен.

Определение кнопки Kaction(), ее состояния и действия показаны в коде ниже:

// Snip from Gemini - Define 2-in1 Mode Transition Button:

         toDesktop = new KAction(q);
         toDesktop->setEnabled(false);
         toDesktop->setText(tr("Switch to Desktop"));
SIGNAL(triggered(Qt::MouseButtons,Qt::KeyboardModifiers)), q, SLOT(switchDesktopForced()));
         connect(toDesktop,
SIGNAL(triggered(Qt::MouseButtons,Qt::KeyboardModifiers)), q, SLOT(switchToDesktop()));
sketchView->engine()->rootContext()->setContextProperty("switchToDesktop
sketchView->Action", toDesktop);

Затем разработчики занялись обработкой событий, переключаемых кнопкой. Сначала нужно проверить последнее известное состояние системы, затем идет смена режима:

// Snip from Gemini - Perform 2-in1 Mode Transition via Button:

#ifdef Q_OS_WIN
bool MainWindow::winEvent( MSG * message, long * result ) {
     if (message && message->message == WM_SETTINGCHANGE && message->lParam)
     {
         if (wcscmp(TEXT("ConvertibleSlateMode"), (TCHAR *) message->lParam) == 0)
             d->notifySlateModeChange();
         else if (wcscmp(TEXT("SystemDockMode"), (TCHAR *)
message->lParam) == 0)
             d->notifyDockingModeChange();
         *result = 0;
         return true;
     }
     return false;
}
#endif

void MainWindow::Private::notifySlateModeChange()
{
#ifdef Q_OS_WIN
     bool bSlateMode = (GetSystemMetrics(SM_CONVERTIBLESLATEMODE) == 0);

     if (slateMode != bSlateMode)
     {
         slateMode = bSlateMode;
         emit q->slateModeChanged();
         if (forceSketch || (slateMode && !forceDesktop))
         {
             if (!toSketch || (toSketch && toSketch->isEnabled()))
                 q->switchToSketch();
         }
         else
         {
                 q->switchToDesktop();
         }
         //qDebug() << "Slate mode is now"<< slateMode;
     }
#endif
}

void MainWindow::Private::notifyDockingModeChange()
{
#ifdef Q_OS_WIN
     bool bDocked = (GetSystemMetrics(SM_SYSTEMDOCKED) != 0);

     if (docked != bDocked)
     {
         docked = bDocked;
         //qDebug() << "Docking mode is now"<< docked;
     }
#endif
}

Этап 3 — Тестирование и отладка.Использование палитры при сенсорном управлении или при управлении мышью очень просто, но сама рабочая область должна сохранять фокус и масштабирование согласно ожиданиям пользователей. Поэтому увеличение размера всех объектов было невозможно. Для сенсорного взаимодействия в режиме планшета можно увеличить элементы управления, но самим изображением на экране нужно управлять на другом уровне, чтобы сохранить ожидаемое удобство работы. Обратите внимание на видео (Рис. 3), что изображение в области редактирования сохраняет неизменный размер на экране в обоих режимах. В этой области разработчикам пришлось потрудиться, чтобы сохранить одинаковую площадь пространства экрана. Еще одна проблема состояла в том, что оба пользовательских интерфейса работали одновременно: это сильно влияло на производительность, поскольку оба интерфейса совместно использовали одни и те же графические ресурсы. Оба интерфейса были доработаны таким образом, чтобы использовать разные ресурсы, а приоритет в системе отдавался бы активному интерфейсу.

Заключение

Как видно, добавление поддержки переключения режимов 2 в 1 в приложении — достаточно простой процесс. Нужно тщательно изучить, как пользователи будут взаимодействовать с вашим приложением в каждом из режимов. Прочтите статью Intel «Write Transformational Applications for 2 in 1 Devices Based on Ultrabook™ Designs» для получения дополнительной информации о создании приложений с изменяющимся пользовательским интерфейсом. Для Krita Gemini было принято решение реализовать простые возможности рисования в режиме планшета, а ретушировать и прорабатывать детали рисунков в режиме ноутбука. Что вы можете выделить в вашем приложении, предлагая его пользователям в режиме планшета по сравнению с режимом ноутбука?

Дополнительная информация

1. Intel.com: Introducing the Intel Developer Zone
2. Intel.com: 2 in 1 Information
3. Intel.com: Touch Developer Guide for Ultra Mobile Devices
4. Intel.com: Developer's Guide for Intel® Processor Graphics for 4th Generation Intel® Core™ Processor
5. Intel.com: Ultrabook and Tablet Windows* 8 Sensors Development Guide
6. Intel® Article: Ideum GamePlay: Touch Controls for Your Favorite Games
7. Intel® Article: Designing for Ultrabook Devices and Touch-enabled Desktop Applications
8. Intel® Article: How to Write a 2 in 1 Aware Application by Stephan Rogers
9. Intel® Article: Mixing Stylus and Touch Input on Windows* 8 by Meghana Rao
10. Intel® Developer Forum 2013 Presentation (PDF): Write Transformational Applications for 2 in 1 Devices Based on Ultrabook™ Designs by Meghana Rao
11. Krita Gemini*: General Information
12. Krita Gemini: Executable download (scroll to Krita Gemini link)
13. Krita Gemini Mode Transition: Source Code Download
14. KO GmbH Krita Gemini: Source Code and License Repository

Другие статьи Intel

Ultrabook Device and Tablet Windows Touch Developer Guide
All-in-One PC: What are the Developer Possibilities?
Windows 8* Store vs Desktop App Development

Дополнительные ресурсы Intel

Intel® Developer Zone 
Intel® Graphics Performance Analyzers 
Developing Power-Efficient Apps for Ultrabook™ Devices 
Ultrabook™ App Lab 
Windows* 8.1 Preview – What’s New for Developers
Ultrabook™ and Tablet Windows* 8 Sensors Development Guide

Об авторе

Тим Дункан — инженер Intel. Друзья называют его Мистер Гаджет. В настоящее время он помогает разработчикам встраивать новые технологии в создаваемые решения. Тим обладает многолетним опытом работы в отрасли, сфера его профессиональных интересов весьма обширна — от производства микросхем до интеграции систем. Найдите его на сайте Intel® Developer Zone: Tim Duncan (Intel).

Intel и эмблема Intel являются товарными знаками корпорации Intel в США и в других странах.
© Intel Corporation, 2013—2014. Все права защищены.
*Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

Загрузить статью [Eng., PDF 632KB]

GestureWorks Gameplay— это новый способ взаимодействия с популярными играми на ПК. Программа Gameplay для Windows 8 позволяет игрокам использовать и создавать собственные виртуальные контроллеры для сенсорного управления, которые можно применять в существующих играх. Каждый виртуальный контроллер добавляет кнопки, жесты и прочие элементы управления, которые сопоставляются с поддерживаемыми игрой средствами управления. Кроме того, игроки могут применять сотни индивидуально настраиваемых жестов для взаимодействия с игрой на экране. Сотрудничество компании Ideum с корпорацией Intel позволило получить доступ к технологиям и инженерным ресурсам, чтобы реализовать возможности сенсорного управления в Gameplay.

Посмотрите этот короткий ролик, поясняющий принцип работы Gameplay.

Виртуальные контроллеры

В отличие от традиционных игровых контроллеров виртуальные контроллеры полностью настраиваются, а игроки могут обмениваться ими с друзьями. Программа Gameplay работает на планшетах с Windows 8, ультрабуках, устройствах 2 в 1, моноблоках и даже мультисенсорных планшетахс большими экранами.

Рисунок 1‒ Программа Gameplay в действии на планшете с процессором Intel Atom

«Виртуальный контроллер реален! Программа Gameplay охватывает сотни игр для ПК, не поддерживающих сенсорное управление, и позволяет играть в них на совершенно новом поколении мобильных устройств, — говорит Джим Спадаччини (Jim Spadaccini), директор компании Ideum, создавшей GestureWorks Gameplay. — Виртуальные контроллеры Gameplay лучше физических контроллеров, поскольку их можно полностью настраивать и изменять. Мы с интересом ожидаем распространения Gameplay среди игроков».

Рисунок 2‒ Главная страница Gameplay

Вместе с GestureWorks Gameplay поставляется несколько десятков уже готовых виртуальных контроллеров для популярных игр для Windows (в настоящее время поддерживается свыше 116 уникальных наименований). В программе Gameplay пользователи также могут настраивать существующие контроллеры и изменять их раскладку. Программа также включает удобное в использовании средство создания виртуальных контроллеров: пользователи могут создавать собственные контроллеры для множества популярных игр для Windows, распространяемых с помощью службы Steam.

Рисунок 3‒ Раскладка виртуального контроллера

Пользователи могут размещать джойстики, переключатели, колесики прокрутки и кнопки в любых местах экрана, изменять размер и прозрачность элементов управления, добавлять цвета и подписи. Также можно создавать несколько представлений разметки и переключаться между ними в любой момент игры. Благодаря этому пользователь может создавать представления для разных действий в игре, например в ролевой игре можно создать одно представление для боя, а другое — для управления снаряжением.

Рисунок 4‒ Глобальное представление жестов виртуального контроллера

Программа Gameplay, в основе которой лежит движок обработки жестов GestureWorks Core, поддерживает свыше 200 глобальных жестов. Простейшие глобальные жесты, такие как касание, перетаскивание, сведение/разведение пальцев и поворот, поддерживаются по умолчанию, но также настраиваются. Это позволяет расширять возможности контроллеров и применять мультисенсорные жесты для дополнительного управления в играх на ПК. Например, определенные действия или боевые приемы в шутерах от первого лица можно активировать одним жестом вместо нажатия нескольких кнопок. Gameplay также включает экспериментальную поддержку акселерометров: в гонках можно поворачивать, наклоняя ультрабук или планшет. Программа обнаруживает переключение устройств 2 в 1 в режим планшета, чтобы при необходимости включить виртуальный контроллер.

Проблемы, возникшие при разработке

Разрабатывать такую удобную программу было непросто. Для воплощения идеи Gameplay в жизнь потребовалось преодолеть ряд технических проблем. Некоторые проблемы удалось решить традиционными методами программирования, для других проблем потребовались более изощренные решения.

Поддержка переключения 2 в 1

Еще в самом начале разработки Gameplay, мы решили добавить поддержку устройств 2 в 1. Идея была в том, что приложение работает постоянно, но отображение контроллеров не происходит в настольном режиме. В случае перехода в режим планшета, контроллер Gameplay начинает отображаться для обеспечения сенсорного управления в приложении. Активируйте поддержку в настройках виртуального контроллера на устройствах 2 в 1.

Рисунок 5‒ Настройки виртуального контроллера

Для тех, кто хочет получить дополнительную информацию о переключении режимов в устройствах 2 в 1, в разделе Ресурсы приведена отличная рекомендация с примерами кода.

Внедрение DLL

Внедрение DLL (DLL injection) — это метод, используемый для выполнения кода внутри адресного пространства другого процесса путем загрузки внешней библиотеки динамической компоновки. Внедрение DLL часто используется внешними программами для вредоносных целей, но эту технологию можно использовать и в «мирных целях», чтобы расширить возможности программы так, как это не было предусмотрено ее авторами. В программе Gameplay нам требовался способ вставки данных в поток входных данных процесса (запущенной игры), чтобы сенсорный ввод можно было преобразовать во входные данные, распознаваемые игрой. Из множества методов реализации внедрения DLL программисты Ideum выбрали вызовы подключения к Windows в API SetWindowsHookEx. В конечном итоге выбрали подключения к определенным процессам вместо глобальных подключений по соображениям производительности.

Запуск игр из сторонней оболочки запуска

Мы изучили два метода подключения к адресному пространству целевых процессов. Приложение может подключиться к адресному пространству запущенного процесса, или же приложение может запустить целевой исполняемый файл в качестве дочернего процесса. Оба метода вполне жизнеспособны. Тем не менее на практике оказалось, что намного проще отслеживать и перехватывать процессы или потоки, созданные целевым процессом, если наше приложение является родительским по отношению к этому целевому процессу.

При этом возникает проблема для клиентов приложений, таких как Steam и UPlay, запускаемых при входе пользователя в систему. В Windows не предоставляется гарантированного порядка запуска процессов, а процесс Gameplay должен быть запущен до этих процессов, чтобы получить возможность подключаться к управлению. Gameplay решает эту проблему путем установки компактной системной службы, которая отслеживает запуск приложений при входе пользователя в систему. Если запускается одно из интересующих нас клиентских приложений, Gameplay может подключиться к ней в качестве родительского процесса, и тогда элементы управления будут отображаться нужным образом.

Полученный опыт

Фильтрация данных мыши

При разработке мы столкнулись с тем, что в некоторых игра неверно обрабатывались входные данные виртуальной мыши, полученные с сенсорного экрана. Эта проблема чаще всего возникала в шутерах от первого лица или в ролевых играх, где при помощи мыши выбирается направление взгляда. Проблема состояла в том, что входные данные мыши, полученные с сенсорного экрана, были абсолютными по отношению к какой-либо точке на экране, а значит, и в игровой среде. Изза этого сенсорный экран был практически бесполезным в качестве устройства для управления направлением взгляда с помощью мыши. Решить эту проблему удалось путем фильтрации входных данных мыши, перехватывая поток входных данных игры. Это дало возможность имитировать входные данные мыши для управления направлением взгляда с помощью такого экранного элемента управления, как джойстик. Потребовалось немало времени и усилий, чтобы настроить чувствительность джойстика и зону нечувствительности, чтобы они по ощущениям совпадали с мышью, но когда это было сделано, все прекрасно заработало. Это исправление можно увидеть в действии в таких играх, как Fallout: New Vegasили The Elder Scrolls: Skyrim.

Отбор игр для сенсорного управления

Разработчики Ideum потратили немало времени, настраивая виртуальные контроллеры для оптимального удобства в играх. Различные элементы игр определяют пригодность игры для Gameplay. Ниже приводятся общие правила, определяющие, какие типы игр хорошо работают с Gameplay.

Удобство игры — это важный фактор использования или отказа от использования Gameplay для этой игры, но самый важный фактор — это стабильность. Некоторые игры вообще не работают ни с подключением к управлению, ни с внедрением входных данных, ни с наложением. Это может происходить по разным причинам, но чаще всего сама игра отслеживает свое пространство в памяти или поток входных данных, чтобы избежать подмены данных. Программа Gameplay сама по себе является вполне безопасной и разрешенной, но она использует технологии, которые также применяются для вредоносных целей, поэтому, к сожалению, некоторые игры не будут работать с Gameplay, если в них нет встроенной поддержки сенсорного управления.

Отзывы пользователей

Хотя программа Gameplay 1.0 пока находится на довольно ранней стадии разработки, мы получили интересные отзывы пользователей в отношении сенсорного управления играми на ПК. В полученных отзывах уже можно проследить некоторые вполне ясные тенденции. Во-первых, ясно, что всем в целом нравится возможность настраивать сенсорный интерфейс в играх. Остальные отзывы касаются настройки интерфейса в играх в некоторых ключевых областях:

• Многие виртуальные контроллеры не очень удобны для левшей. Именно это было изменено раньше всего во многих опубликованных виртуальных контроллерах.
• Чаще всего пользователи изменяют размер кнопок и их расположение, поэтому Ideum рассматривает возможность добавления автоматической калибровки кнопок по размеру руки в будущей версии Gameplay.
• Многие пользователи предпочитают использовать сенсорную прокрутку, а не дискретное касание и отпускание.

Мы ожидаем, что удастся выявить и другие тенденции по мере увеличения количества созданных виртуальных контроллеров.

Заключение

GestureWorks Gameplay привносит возможности сенсорного управления в ваши любимые игры. Для этого используется сочетание визуального наложения элементов управления и поддерживаются дополнительные способы взаимодействия, такие как жесты, акселерометры и переключение трансформеров в разные режимы работы. Наибольший интерес при работе над этим проектом представляют отзывы пользователей. Люди очень рады возможности играть на ПК с сенсорным управлением. Они с огромным удовольствием наслаждаются своими любимыми играми, применяя сенсорный экран.

Об авторах

Erik Nimeyer работает инженером по программному обеспечению в отделе Software and Solutions Group корпорации Intel. Эрик занимался оптимизацией производительности приложений на микропроцессорах Intel в течение почти 15 лет. Его специализация — разработка новых пользовательских интерфейсов и настройка на уровне микроархитектуры. В свободное от работы время он занимается альпинизмом. Связаться с ним можно по адресу erik.a.niemeyer@intel.com.

Chris Kirkpatrick — инженер по программному обеспечению в отделе Intel Software and Services Group. Он поддерживает графические решения Intel для мобильных платформ в группе Visual & Interactive Computing Engineering. Он является бакалавром компьютерных наук в Университете штата Орегон. Связаться с ним можно по адресу chris.kirkpatrick@intel.com.

Ресурсы

https://gameplay.gestureworks.com/

Дополнительные материалы

How to Write a 2-In-1 Aware Application: /en-us/articles/how-to-write-a-2-in-1aware-application
Krita Gemini Development of a 2-In-1 Aware Application with Dynamic UI for Laptop and Tablet Modes: /en-us/articles/krita-gemini-twice-as-nice-on-a-2-in-1
Detecting 2 in 1 Conversion Events & Screen Orientation in a 2 in 1 Device: /en-us/articles/detecting-slateclamshell-mode-screen-orientation-in-convertible-pc

Видео

Gestureworks Gameplay on an Ideum 46 Inch Multi-Touch Table

Содержание

Предисловие. Что, почему и откуда? 1

Глава 1: Введение. 2

Глава 2: P-состояния, Снижение энергопотребления без ущерба для производительности. 3

Глава 3: С-состояния ядер. Подробности. 5

Глава 4: Пакетные C-состояния. Подробности. 8

Глава 5: Интуитивное описание состояний электропитания с помощью человечков и лампочек. 12

Заключение. 15

Приложение: C-Состояния, P-Состояния, а где же T-Состояния?. 16

Справочные материалы. 18

Примечания. 18

Предисловие. Что, почему и откуда?

В этой статье объединена серия публикаций, посвященных состояниям управления электропитанием. Эта серия входит в еще более крупный набор блогов по самым разным темам, связанным с управлением электропитанием, включая состояния управления электропитанием (эта серия), состояния электропитания в режимах «Турбо» и в режиме hyper-threading, настройку и политики управления электропитанием. Содержание этих публикаций будет полезно для всех, хотя здесь описывается только сопроцессор Intel® Xeon Phi™. Исключение составляет лишь серия по настройке, которая по своей природе в большей степени зависит от платформы; она посвящена сопроцессору Intel® Xeon Phi™ и набору программ Intel® Manycore Platform Software Stack (MPSS). В дополнение к этому набору блогов по управлению электропитанием обратите внимание на еще две вспомогательных подборки: серию по измерению производительности[i], и еще один набор более ранних публикаций на различные темы, например о том, откуда берется C*V²*f.

Статья, которую вы сейчас читаете, была изначально опубликована в следующей серии из весьма непоследовательно названных блогов:

• Управление электропитанием в сопроцессорах Intel Xeon Phi, часть 0.Введение
• Управление электропитанием в сопроцессорах Intel Xeon Phi, часть 1. P-states, снижение энергопотребления без ущерба для производительности
• Управление электропитанием в сопроцессорах Intel Xeon Phi, часть 2а. C-states ядер, подробности
• Управление электропитанием в сопроцессорах Intel Xeon Phi, часть 2b. C-states пакетов, подробности
• Управление электропитанием в сопроцессорах Intel Xeon Phi, часть 3. Интуитивное описание состояний электропитания с помощью человечков и лампочек

Кроме того, есть еще одна статья в приложении:

• C-Состояния, P-состояния а где же T-Состояния?

На портале Intel® Developer Zone вы найдете отдельные блоги, перечисленные в еще одной статье: Список полезных статей, блогов и ссылок по электропитанию и управлению электропитанием.

Итак, устраивайтесь поудобнее и постарайтесь получить удовольствие от ознакомления с захватывающей темой управления электропитанием.

Глава 1. Введение для пытливых умов

Какие именно состояния электропитания существуют для сопроцессора Intel Xeon Phi? Что происходит в каждом из этих состояний? Было бы интересно знать. Если вы интересуетесь высокопроизводительными вычислениями, то и вам эти знания пригодятся.

Но это не будет глубокий, исчерпывающее подробный и крайне технический научный труд, посвященный управлению электропитанием. Если вам нужен именно такой материал, предлагаю прочесть руководство разработчиков программного обеспечения (SDG) по сопроцессору Intel Xeon Phi[ii].Но предупреждаю: когда в разделе руководства разработчиков, посвященном управлению электропитанием, заходит речь о создателях программного обеспечения (т. е. о программистах), явно или неявно, подразумеваемся не мы с вами. Целевая аудитория этого руководства — разработчики операционных систем и драйверов. Кстати, в прошлой жизни я был одним из таких разработчиков. Одна из целей этой серии блогов — рассмотрение управления электропитанием с точки зрения разработчика приложений, т. е. меня или вас, а не с точки зрения создателя операционных систем или драйверов.

Кроме того, я не стану рассказывать о том, что такое С-, Р- и РС-состояния. Если вам требуется ознакомиться с этими понятиями перед чтением нашей серии блоков, рекомендую (без ложной скромности) мою прежнюю серию блогов, посвященную именно этой теме. См. http://software.intel.com/en-us/user/266847/track. Непросто выделить нужные публикации по управлению электропитанием из всех прочих моих публикаций в форумах и видеороликов, поэтому я перечислил наиболее важные публикации в примечании[iii].

Если кратко, бывают Р-состояния пакета, С-состояния ядер (иногда их называют СС-состояния) и С-состояния пакета (РС-состояния). Также сопроцессор может работать в режиме "Turbo"³. Р-состояний ядер не бывает.

Хост и сопроцессор совместно отвечают за управление электропитанием сопроцессора. В некоторых операциях по управлению электропитанием сопроцессор действует автономно. В других случаях хост принимает ответственность на себя и сам управляет электропитанием, а иногда даже переопределяет действия сопроцессора.

В дальнейшей серии я расскажу о пакетных Р-состояниях (включая режим "Turbo"[iv]), C-состояниях ядер и пакетных РС-состояниях. Я также расскажу о том, как вы, будучи разработчиком приложений, можете управлять электропитанием сопроцессора..

И еще одно замечание. Я не гарантирую, что все выпуски сопроцессоров Intel Xeon Phi (т. е. типы сопроцессоров) поддерживают все эти функции управления электропитанием.

Глава 2. P-состояния. Снижение энергопотребления без ущерба для производительности

С самого начала могу заявить, что Р-состояния не повлияют на производительность приложения. Тем не менее они важны для приложения по другим соображениям. Поскольку большинство читателей этого блога ничего не принимают на веру, относятся ко всей воспринимаемой информации критически и скептически (будучи инженерами и учеными), я подкреплю это мое заявление доказательствами.

Р-состояния представляют собой пары значений напряжения и частоты, определяющие скорость работы сопроцессора и потребляемую им мощность. Чем ниже рабочее напряжение процессора, тем меньше электроэнергии он потребляет. (В одной из более ранних публикаций я пояснял это на очень высоком техническом уровне.) Поскольку вместе с напряжением снижается и частота, при этом уменьшается скорость вычислений. Так и вижу, как у вас зреет вопрос: «Да разве могут возникнуть ситуации в приложениях для высокопроизводительных вычислений, когда мне потребуется включить Р-состояния и снизить производительность приложения?» Применение Р-состояний менее важно в области высокопроизводительных вычислений, чем в средах с менее интенсивной нагрузкой, таких как клиентские компьютеры и серверы данных. Но даже в среде сопроцессоров и высокопроизводительных вычислений длительные состояния бездействия довольно часто возникают в промежутках между крупными вычислительными задачами. Например, если вы используете модель разгрузки, сопроцессор с высокой вероятностью не будет использоваться в периодах между разгрузками. Кроме того, нативное приложение, выполняющееся на сопроцессоре, зачастую будет по разным причинам находиться в состоянии бездействия, например ожидать следующей порции данных для обработки.

Программа управления электропитанием сопроцессора поддерживает Р-состояния от Р0 до Pn. Количество Р-состояний, поддерживаемых каждым выпуском (типом) сопроцессора, может различаться, но всегда составляет не менее двух. Кроме того, некоторые типы поддерживают Р-состояния «Турбо». Программа управления электропитанием сопроцессора обрабатывает переходы из одного Р-состояния в другое. Программа управления электропитанием хоста в этом практически не участвует.

Возникает закономерный вопрос: как это все повлияет на производительность? Мы же все-таки работаем в среде высокопроизводительных вычислений. Ответ прост: никакого практического влияния на производительность вычислений нет. Не сомневаюсь, что сейчас у вас возникло уже несколько вопросов:

(a)    “Минутку! Как это возможно? Если сопроцессор снижает скорость работы процессора, уменьшая его частоту, как это может не повлиять на производительность моего приложения?”

(b)   “Мне просто нужно, чтобы приложение работало как можно быстрее. Зачем вообще мне заботиться о сокращении потребления электроэнергии?”

Сначала рассмотрим вариант Б. Я понимаю, что электропитание не является наиболее приоритетным вопросом для вас, как для разработчика приложений. Но все равно оно косвенно влияет на производительность приложения. Повышенное потребление электроэнергии связано с такими вещами, как более высокие затраты на помещение, повышенный расход электричества на охлаждение и кондиционирование воздуха, необходимость большей площади помещения и т. п. Просто об этом должны заботиться не мы (программисты), а наши коллеги — администраторы, системные архитекторы, управляющие помещениями и так далее.

Говоря по правде, вам тоже следует думать об этом. Это влияет на ваше приложение с весьма важной стороны, хоть это и не всегда очевидно. Если в вычислительном центре удастся снизить расход электроэнергии без потери производительности, это означает, что в этом же пространстве можно установить больше процессоров, не превышая при этом отведенную норму электропитания. То есть, образно говоря, вы «получаете больше за те же деньги». А это очень хорошо для вас как для программиста или ученого. Снижение требуемой потребляемой мощности означает, что в меньшем пространстве можно разместить больше процессоров. Это, в свою очередь, означает, что вы как разработчик приложений или ученый можете заниматься не только более масштабными задачами (в системе больше ядер), но и обрабатывать эти задачи быстрее (ниже задержки передачи данных между ядрами).

Вернемся к Р-состояниям. Р-состояния теоретически повлияют на производительность, но не так, чтобы это сказалось на работе высокопроизводительных приложений. Как это возможно? Дело в переходах между Р-состояниями. Также следует помнить об использовании процессора. Программное обеспечение управления электропитанием периодически отслеживает использование процессора. Если использование ниже определенного порога, Р-состояние увеличивается, то есть процессор переходит в следующее состояние энергоэффективности. Ключевое слово в предыдущем предложении — «использование». Как вы думаете, каково будет использование процессора при выполнении ресурсоемкой задачи, связанной с высокопроизводительными вычислениями? В идеале оно должно быть как можно ближе к 100 %. А в каком Р-состоянии будет выполняться ваше приложение при таком использовании процессора? Это Р0, самое быстрое Р-состояние (если не считать режим «Турбо»). Следовательно, Р-состояния с самым высоким уровнем экономии электричества не повлияют на ваше приложения: ситуация, в которой процессор, поддерживающий ваше хорошо настроенное высокопроизводительное приложение, мог бы войти в одной из таких состояний, просто не возникнет.

Итак, все высокопроизводительные части приложения всегда будут использовать процессоры почти на 100 %. Использование, близкое к 100 %, практически всегда гарантирует самое быстрое Р-состояние, то есть Р0. Следовательно, Р-состояния не влияют на производительность приложений.

Как заставить мое приложение работать в одном из этих режимов «Турбо»? Этого делать нельзя, потому что это слишком опасно. Очень легко сделать незначительную ошибку, которая повлечет перегрев и повреждение сопроцессора. Если процессор поддерживает «Турбо», предоставьте управление этим режимом операционной системе.

Глава 3. C-состояния ядер: подробности

БАЗОВЫЕ СВЕДЕНИЯ: КРАТКО О СОСТОЯНИЯХ БЕЗДЕЙСТВИЯ

Вот краткое описание С-состояний. С-состояния — это состояния экономии электроэнергии при бездействии (в отличие от Р-состояний, представляющих собой состояния экономии электроэнергии при работе). В Р-состоянии процессор продолжает выполнять инструкции, а в С-состоянии (кроме состояния С0) процессор бездействует, никакие инструкции не выполняются. Можно привести такую аналогию: бездействующий процессор подобен дому, в котором горит весь свет, но никого нет. Потребление всей этой электроэнергии не служит никаким полезным целям, разве что приносит некоторую прибыль электрической компании. Как лучше поступить? Если дома никого нет, то есть дом бездействует, зачем же оставлять свет включенным? То же самое применимо и к процессору. Если им никто не пользуется, зачем подавать питание на неиспользуемые элементы и расходовать электричество? Можно отключить их и сэкономить.

С0 является «нулевым» состоянием электропитания: в этом состоянии ядро фактически работает, не бездействует.

РАЗНИЦА МЕЖДУ СОСТОЯНИЯМИ БЕЗДЕЙСТВИЯ ЯДЕР И ПАКЕТА

Сопроцессор содержит до 60 (или даже больше) ядер в одном пакете. Состояния бездействия ядер (C-состояния) действуют для каждого ядра: одно из этих 60 ядер может быть в состоянии C0, т. е. ядро работает и не бездействует, тогда как соседнее ядро может находиться в состоянии глубокой экономии электроэнергии C6. PC-состояния — это состояния бездействия всего пакета, то есть состояния экономии электроэнергии для всех 60 ядер и поддерживающих электронных компонентов на кристалле. Как можно догадаться, чтобы перевести пакет в состояние PC-6, все ядра должны находиться в состоянии С6. Почему? Поскольку пакет обладает функциональностью, поддерживающей все ядра, «отключение» определенных электронных компонентов пакета влияет на все ядра.

КАКИЕ СУЩЕСТВУЮТ СОСТОЯНИЯ БЕЗДЕЙСТВИЯ ЯДЕР?

У каждого ядра может быть два состояния бездействия, С1 и С6 (не считая С0).

Переход от С0 к С1. Посмотрите на рис. 1 Состояние С1 наступает, когда все 4 аппаратных потока, поддерживаемых ядром, выполняют инструкцию HALT. Давайте посмотрим на каждый аппаратный поток с точки зрения операционной системы: 4 аппаратных потока рассматриваются как 4 отдельных ЦП (от ЦП 0 до ЦП 3). Этап 1. Первые три ЦП, принадлежащие данному ядру, выполняют инструкцию HALT. Этап 2. Последний ЦП (ЦП 0) пытается выполнить инструкцию HALT. Этап 3. Он прерывается для процедуры сбора данных резидентности бездействия. Эта процедура, как вы догадались, собирает данные резидентности бездействия и сохраняет их в структуре данных, доступной для ОС. Затем ЦП 0 выполняет инструкцию HALT. Этап 4. На этом этапе все ЦП останавливаются, а ядро переходит в состояние C1. В состоянии ядра C1 (и его ЦП) снижается его тактовая частота[v].

После входа ядра в состояние C1 на сцену выходит программа управления электропитанием сопроцессора. Ей нужно определить, целесообразно ли дальнейшее отключение ядра и перевод его в состояние С6. В состоянии ядра C6 остальные части ядра отключаются, их потребляемая мощность ограничивается. Помните, что программа управления электропитанием сопроцессора выполняется на ядре ОС (обычно это ядро 0), поэтому отключения других ядер на него не влияют.

Решения какого типа должна принимать программа управления электропитанием сопроцессора? Существует два основных решения, описанных в предыдущей главе. Вопрос 1. Будет ли (возможно) достигнута экономия электроэнергии? Вопрос 2. Сможет ли задержка, требуемая для перезапуска, отрицательно повлиять на производительность процессора или применений, выполняемых на этом процессоре? Эти решения соответствуют двум основным сценариям и показаны на рисунках 2 и 3. В сценарии 1 программа управления электропитанием сопроцессора определяет, насколько далеко следующее запланированное или предполагаемое прерывание. Если прерывание должно произойти достаточно скоро, не имеет смысла отключать ядро, поскольку увеличивается длительность задержки, необходимой для возврата ядра в состояние С0. Как и в жизни, процессор ничего не получает бесплатно. За переход в более глубокое С-состояние процессор расплачивается повышением задержек, связанных с возвратом ядра/пакета в рабочее состояние. В сценарии 2 программа управления электропитанием сопроцессора изучает историю деятельности ядра (то есть его аппаратных потоков) и определяет по чередованию периодов работы (состояние С0) и бездействия (С1), даст ли какую-либо экономию переход в состояние С6.

При ответе «да» на оба этих вопроса ядро переходит в состояние С6.

После входа в состояние ядра C6 процессор принимает решение о том, может ли он перейти в одно из состояний бездействия пакета. Этому вопросу будет посвящена следующая публикация в моем блоге.

Глава 4. C-состояния пакета: подробности

ЗАМЕЧАНИЕ О ТЕРМИНОЛОГИИ.

Если вы прочтете SDG (руководство разработчика программного обеспечения по сопроцессорам Intel Xeon Phi), то вы обнаружите там множество не всегда понятных названий и сокращений. Вот как это все расшифровывается:

Пакетный Auto C3[vi] - также называется Auto-C3, AutoC3, PC3, C3, Auto-PC3 и Package C3.

Пакетный Deep-C3 - также называется PC3, DeepC3, DeeperC3, Deep PC3 и Package C3 (я не повторяюсь, это вам показалось).

Пакетный C6 - также называется PC6, C6 и Package C6.

БАЗОВЫЕ СВЕДЕНИЯ: ЧТО ТАКОЕ «ВНЕЯДЕРНЫЕ КОМПОНЕНТЫ»?

Перед более подробным рассмотрением С-состояний пакета сначала несколько слов о компонентах современных процессоров Intel®. Всю электронную «начинку» процессора очень удобно разделить на две части: то, что образует ядра (конвейер, вычислительные блоки, регистры, кеш и т. д.) и все остальное (вспомогательные элементы). Оказывается, что это «все остальное» можно снова разделить на вспомогательные элементы, не связанные напрямую с производительностью (например, интерфейс с PCI Express), и на элементы, связанные с производительностью (например, шины, соединяющие ядра). В Intel для вот этих вспомогательных элементов, напрямую влияющих на производительность оптимизированных приложений, придумали обозначение «внеядерные компоненты».

Вернемся к нашим С-состояниям.

ЗАЧЕМ НУЖНЫ C-СОСТОЯНИЯ ПАКЕТА?

Помимо ограничения тактов каждого ядра, какие еще методики можно использовать для дополнительной экономии электроэнергии? Вот простейший и даже банальный пример того, что можно сделать: отключить питание всего процессора. При этом потребление электроэнергии будет равно нулю, хотя и недостатки такого «выдергивания из розетки» также очевидны. Лучше избирательно отключать более глобальные компоненты процессора таким образом, чтобы можно было относительно быстро вернуть процессор в полностью функциональное состояние (С0).

Именно для этого и используются пакетные С-состояния: для последовательного отключения дополнительных компонентов с целью дальнейшей экономии электроэнергии. Поскольку мы уже отключили все компоненты пакета, связанные с ядрами, оставшиеся компоненты являются общими и необходимыми для всех ядер, поэтому их совокупность мы и называем пакетом.

КАКИЕ СУЩЕСТВУЮТ СОСТОЯНИЯ БЕЗДЕЙСТВИЯ ПАКЕТА?

Уважаемые читатели, существуют три пакетных С-состояния: Auto-C3, Deep-C3 и (пакетный) C6. Напоминаю, что это все пакетные С-состояния, то есть все аппаратные потоки/ЦП во всех ядрах находятся в состоянии HALT. Я догадываюсь, о чем вы думаете: «Если все ядра сопроцессора находятся в состоянии HALT, как может работать программное обеспечение управления электропитанием?» Хороший вопрос. Но ответ, если подумать, вполне очевиден. Если программное обеспечение управления электропитанием не может выполняться на сопроцессоре, то где может? Разумеется, на хосте.

За управление электропитанием сопроцессора Intel® Xeon Phi™ отвечают два компонента: программа управления электропитанием, выполняющаяся на сопроцессоре и компонент управления электропитанием драйвера сопроцессора MPSS, выполняющийся на хосте. См. рис. 1. Сопроцессор управляет переходом в различные С-состояния ядра и выходом из них. Разумеется, когда программа управления электропитанием не может выполняться на сопроцессоре, например при состояниях пакета Deep-C3 или C6, управление берет на себя хост. Управление пакетным состоянием Auto-C3 осуществляет и хост, и сопроцессор.

ЧТО ОТКЛЮЧАЕТСЯ В С-СОСТОЯНИЯХ ПАКЕТА?

Я собирался переделать эту таблицу, но в ней все настолько ясно, что я ее просто скопировал. Это таблица 3-2 из руководства разработчиков программного обеспечения (SDG) по сопроцессору Intel® Xeon Phi™.

Немного подробнее:

Пакетный Auto-C3: ограничение частоты кольца и внеядерных компонентов

Пакетный Deep-C3: снижение напряжения VccP

Пакетный C6: отключение напряжения VccP (т. е. отключение питания ядер, кольца и внеядерных компонентов)

TSC и LAPIC — это тактовые генераторы, которые останавливаются при отключении внеядерных компонентов. Их следует правильным образом задать при повторной активации пакета. PC3 — это то же самое, что состояние пакета Auto-C3.

КАК ОПРЕДЕЛЯЮТСЯ ПЕРЕХОДЫ С-СОСТОЯНИЙ БЕЗДЕЙСТВИЯ ПАКЕТА?

В Auto-C3 пакета: первое состояние пакета, Auto-C3, можно рассматривать как промежуточное. Программа управления электропитанием сопроцессора может инициировать переход в это состояние. Программа управления электропитанием MPSS может переопределить этот запрос при определенных условиях, например если хост «знает», что внеядерная часть сопроцессора по-прежнему работает.

Мы также увидим, что состояние пакета Auto-C3 — единственное, которое может быть инициировано программой управления электропитанием сопроцессора. Поначалу это кажется немного несправедливым, но, если вдуматься, причина очевидна. В начале перехода в состояние пакета Auto-C3 процедура управления электропитанием сопроцессора запущена и может инициировать переход в первое состояние пакета. (Чтобы быть совсем точным, ядро, на котором выполняется программа управления электропитанием, может быстро перейти в состояние С0.)

Ниже состояния Auto-C3 сопроцессор не выполняет код. Переход в более глубокие С-состояния контролируется программой управления электропитанием хоста. Причина не только в том, что к этому моменту собственная программа управления электропитанием сопроцессора уже приостановлена, но и в том, что хост располагает более глобальной информацией о происходящем, например данными о работе внеядерных компонентов после ограничения работы всех ядер, и о трафике в шине PCI Express.

В пакетном Deep-C3 программа управления электропитанием хоста анализирует историю резидентности бездействия, прерывания (например, трафик PCI* Express) и временные затраты на пробуждение сопроцессора из состояния пакета Deep-C3, чтобы принять решение о том, следует ли переводить процессор из состояния пакета Auto-C3 в состояние пакета Deep-C3.

В пакетномC6 так же, как и в пакетном Deep-C3, но глубже.

Глава 5. Интуитивное описание состояний электропитания с помощью человечков и лампочек

ИНТУИТИВНАЯ ИЛЛЮСТРАЦИЯ ЯДРА И ЕГО АППАРАТНЫХ ПОТОКОВ

Это четвертая публикация в серии записей об управлении электропитанием для сопроцессоров Xeon Phi.

Для тех из вас, кто прочел мой блог с интуитивным введением в сопроцессор Intel Xeon Phi, Сопроцессор Intel Xeon Phi: что это такое и какое мне до этого дело? Часть 3. Если отвлечься от избитой аналогии с зайцам и черепахами,я как-то упомянул «опытных программистов, старательно работающих на своих корпоративных работодателей». Давайте немного расширим эту концепцию. На рис. 6 у нас есть один опытный программист. Он символизирует один аппаратный поток сопроцессора ЦП.

В ядре — 4 аппаратных потока. Посмотрите на рисунок 7. Все настолько очевидно, что я не стану утруждать себя написанием, а вас — чтением многостраничного пояснения. Также изображена и лампочка. Лампочка представляет инфраструктуру, поддерживающую ядро, такую как тактовые контуры и цепи питания.

УПРАВЛЕНИЕ ЭЛЕКТРОПИТАНИЕМ: ЯДРА C0 И C1

Какое отношение все это имеет к управлению электропитанием? Иногда отдельные либеральные студенты гуманитарных направлений заявляют, что инженеры лишены воображения и вообще зануды. Но мы-то с вами знаем, что даже если некоторое занудство нам порой не чуждо, то в отсутствии воображения нас обвинить нельзя. Помня об этом, представьте себе, что на каждом из этих столов стоят компьютеры и настольные лампы.

Ядро в режиме C0: кода хотя бы один опытный программист напряженно работает (т. е. хотя бы один аппаратный поток ядра ЦП выполняет инструкции)

ЦП выполняет инструкцию HALT: когда один из наших опытных программистов заканчивает работу, он выключает свою настольную лампу, выключает компьютер и уходит (т. е. один из аппаратных потоков выполняет инструкцию HALT).

После входа в состояние ядра C1: когда все четыре опытных программиста заканчивают работу, они все выполняют инструкции HALT. Последний из них гасит за собой свет в помещении. (Т. е. снижение тактовой частоты ядра.)

УПРАВЛЕНИЕ ЭЛЕКТРОПИТАНИЕМ: СОСТОЯНИЕ ЯДРА C6

После входа в состояние ядра C6: да, я понимаю, что это очевидно, но мне нравится разговаривать с самим собой. С течением времени все уходят на обед. Поскольку в офисе никого нет, можно отключить еще больше электроприборов (т. е. снижение потребляемой мощности). Впрочем, помните, что работники вернутся после обеда, поэтому нужно иметь возможность быстро включить все выключенное.

УПРАВЛЕНИЕ ЭЛЕКТРОПИТАНИЕМ: СОСТОЯНИЯ ПАКЕТА AUTO-C3, DEEP-C3 И C6

Да, эта аналогия могла вам уже поднадоесть, но мне она нравится, так что продолжаем.

Давайте пройдем немного дальше. Представьте здание, в котором очень много комнат, больше 60. Посмотрите на рисунок 8. Да, я знаю, что у нас в Кремниевой долине опытные программисты работают в великолепных и просторных комнатах, а не в тесных общих офисах. К сожалению, на этом моя аналогия останавливается, потому что мне нужен именно обычный офис.

Вход в состояние пакета Auto-C3: все ушли с этажа, поэтому датчик движения автоматически выключает освещение на этаже. (Т. е. программное обеспечение управления сопроцессором снижает рабочую частоту внеядерных компонентов и прочих вспомогательных элементов кристалла.

Вход в состояние пакета Deep-C3: сейчас выходные, поэтому во всем здании (т. е. в модуле управления электропитанием драйвера сопроцессора MPSS) отключено кондиционирование воздуха и выключена телефонная связь. (Т. е. хост снижает напряжение VccP сопроцессора и заставляет его игнорировать прерывания)

Вход в состояние пакета C6: новогодние каникулы: офис закрыт, все сотрудники добровольно или вынужденно отдыхают, поэтому техническая служба офиса отключила электричество, кондиционирование воздуха, телефоны, серверы, лифты, туалеты и пр. (т. е. хост выключил питание сопроцессора и отключил отслеживание трафика PCI Express*).

УПРАВЛЕНИЕ ЭЛЕКТРОПИТАНИЕМ: ЧЕМ ДАЛЬШЕ, ТЕМ ЧУДЕСНЕЕ

Увлекшись этой нашей аналогией, я решил было расширить ее до комплексов офисных зданий (узел, содержащий несколько сопроцессоров), международных инженерных дивизионов (кластеры, в которых каждый узел содержит несколько сопроцессоров) и до привлечения внешних партнеров (распределенная обработка в глобальной сети). Впрочем, здравый смысл победил, поэтому я отказался от этого замысла.

Заключение

Мы обсудили различные типы состояний управления электропитанием. Это достаточно широкая проблема, но мы сосредоточились на определенной платформе — сопроцессоре Intel® Xeon Phi™. Большинство современных процессоров, будь то процессоры корпорации Intel, корпорации AMD* или встроенные решения, обладают такими состояниями в той или иной разновидности.

Процессоры Intel® поддерживают два типа состояний управления электропитанием: P-состояния (работа) и C-состояния (бездействие). С-состояния, в свою очередь, делятся еще на две категории: состояния ядер и состояния пакета. Р-состояния — это состояния работы (С0) процессора; снижение потребляемой мощности в этих состояниях достигается путем снижения напряжения и частоты процессора. С-состояния — это состояния бездействия; они отключают части процессора, когда ядра простаивают. Существует два типа С-состояний. C-состояния ядер отключают части отдельных ядер/ЦП. Поскольку современные процессоры содержат несколько ядер, С-состояния пакетов отключают электронные элементы, поддерживающие все эти ядра.

Чистый эффект этих состояний заключается в значительном снижении энергопотребления современных процессоров Intel®. Такая экономия электроэнергии может быть весьма значительной, в некоторых случаях потребление электроэнергии снижается на порядок.

Важность экономии потребляемой мощности невозможно переоценить для любых систем, от смартфонов до высокопроизводительных кластеров. Например, снижение потребляемой мощности и энергопотребления отдельных процессоров в кластере для высокопроизводительных вычислений дает возможность установить в этой системе больше процессоров. При этом повышается плотность процессоров, ускоряется обмен информацией между узлами, становится возможным создать гораздо более мощную систему, способную решать более крупные и сложные задачи. На противоположном краю — портативные устройства с пассивным охлаждением, такие как смартфоны и планшеты. В них снижение потребляемой мощности позволяет дольше работать от аккумулятора без подзарядки и исключает проблемы, связанные с охлаждением. Это позволяет устанавливать в такие устройства более мощные процессоры, что, в свою очередь, расширяет возможности этих устройств.

Приложение. C-состояния, P-состояния, а где же T-состояния?

Несколько дней назад мне встретился интересный вопрос: «Важно ли понимать Т-состояния?» Сначала я удивился: «Что еще за Т-состояния?»

Впрочем, изучив материал, я обнаружил, что так называемое Т-состояние действительно существует, но уже не используется, по крайней мере в серийных процессорах Intel® его нет.

Поэтому повторяю: Т-состояния нам безразличны!

На этом более практичные читатели могут перейти к более актуальным темам, а я расскажу немного из истории управления электропитанием.

Когда-то раньше существовали Т-состояния — это были состояния регулировки. Задолго до появления С- и Р-состояний Т-состояния были придуманы, чтобы защитить процессоры от повреждений при авариях, например если при работе процессора на полной мощности отказывал охлаждающий вентилятор. Если простейший правильно расположенный термодатчик определял, что температура достигала уровня, на котором возможны повреждения пакета или его содержимого, аппаратный диспетчер питания переводил процессор в различные Т-состояния в зависимости от температуры: чем выше температура, тем выше Т-состояние.

AКак вы, возможно, догадались, обычный режим работы процессора назывался состоянием Т0. При переходе процессора в более высокое Т-состояние диспетчер ограничивал такты ядер, чтобы замедлить выполнение инструкций и дать процессору возможность «отдохнуть» и остыть. Например, в состоянии Т1 аппаратный диспетчер питания мог ограничить 12 % тактов. Грубо говоря, это означает, что ядро будет работать в течение 78 % времени и «спать» в остальное время. В режиме Т2 такты могли быть ограничены на 25 %. В самых высоких Т-состояниях ограничение тактов могло достигать 90 %. (См. рисунок ниже.)

Рисунок 9. Время выполнения в состояниях Т0/Р0, Р1 и Т1

Обратите внимание, что, в отличие от Р-состояний, не меняется напряжение и частота. Кроме того, в Т-состояниях приложение работает медленнее не потому, что процессор работает медленнее, а потому что процессор периодически приостанавливает работу. С определенной точки зрения можно считать Т-состояние состоянием С-1 с ограничением тактов, где процессор не бездействует, а по-прежнему выполняет полезную работу.

На приведенном выше рисунке в верхней части показано выполнение ресурсоемкой нагрузки при отсутствии перегрева. Внизу показана ситуация с Т-состояниями (т. е. до Р-состояний), когда процессор начинает переключаться между состоянием работы и состоянием бездействия, чтобы остыть. В середине показано, что происходит на современных процессорах, где остывание процессора достигается плавным снижением частоты и напряжения.

Тем из вас, кто не обиделись на меня за небольшой исторический экскурс, я предлагаю еще несколько вполне практических причин, в силу которых следует хотя бы просто знать о существовании Т-состояний как таковых.

(1)    (1) В некоторой современной технической литературе термин «состояния регулировки» относится к Р-состояниям, а не к Т-состояниям.

(2)    (2) Некоторые структуры данных управления электропитанием, в том числе и определяемые стандартом ACPI, по-прежнему содержат неиспользуемое поле Т-состояния. Многие вопросы о Т-состояниях проистекают именно из этого.

(3)    (3) Подозреваю, что Т-состояния могут все еще использоваться в некоторых встроенных процессорах

Справочные материалы

Kidd, Taylor (10/23/13) - “Тэйлор Кидд (23 октября 2013 г.) - «Список полезных статей, блогов и ссылок по электропитанию и управлению электропитанием»,” http://software.intel.com/en-us/articles/list-of-useful-power-and-power-management-articles-blogs-and-references, загружено 24 марта 2014 г.

Интересующиеся управлением электропитанием могут ознакомиться с руководством разработчиков программного обеспечения по сопроцессору Intel Xeon Phi. Там есть схемы состояний и другие интересные вещи. Рекомендую раздел 2.1.13 «Управление электропитанием» и всю главу 3.1 «Управление электропитанием (PM)»: очень полезно почитать, если у вас бессонница.

ПРИМЕЧАНИЕ: Как и во всех прошлых моих публикациях, всю полноту ответственности за предоставленные иллюстрации несу лично я ввиду ненарушения авторских прав и отсутствия художественных способностей.

Примечания

Code Sample

Краткий обзор

Обычно в ОС Windows* для обработки видео используется Direct3D. Однако во многих приложениях неизменность графического интерфейса и внешнего вида при работе на разных платформах обеспечивается за счет возможностей OpenGL*. В последних версиях графических драйверов Intel поддерживается расширение NV_DX_interop, что обеспечи-вает возможность обмена поверхностями между D3D и OpenGL для их последующего использования в Intel® Media SDK. В Intel® Media SDK можно настроить использование Direct3D, а благодаря поддержке NV_DX_interop кадровый буфер Intel Media SDK может использоваться в OpenGL. При этом устраняется необходимость в ресурсоемком копировании текстур из графического процессора в ЦП и обратно для обработки. В данном примере кода и техническом документе приведена процедура настройки использования D3D в Intel® Media SDK для кодирования и декодирования видео, преобразования цветов из цветовой схемы NV12 (стандартный цветовой формат Media SDK) в схему RGBA (стандартный цветовой формат OpenGL) и сопоставления наложения поверхности D3D с на текстурой текстуру OpenGL. В данной процедуре отсутствует этап копирования текстур из графического процессора в ЦП для обработки, что всегда представляло большую сложность при использовании OpenGL с Intel® Media SDK.

Требования к системе

Пример кода написан с помощью Visual Studio* 2013. Он предназначен (1) для демонст-рации работы Miracast и (2) обмена текстурами между Intel® Media SDK и OpenGL. В процессе обмена декодированные поверхности Intel® Media SDK сопоставляются с текстурами OpenGL без необходимости в выполнении копирования, что значительно повышает эффективность работы. При использовании процессоров Haswell и более поздних версий выполняется аппаратное ускорение декодера MJPEG. При использовании процессоров более ранних версий в Media SDK автоматически применяется программный декодер. Необходимо использовать камеру с поддержкой MJPEG (это может быть как встроенная камера, так и камера с подключением через USB).
Большая часть процедур, используемых в примере кода и техническом документе, применимы и для Visual Studio 2012 (за исключением идентификации типа подключения Miracast). Пример кода основан на Intel® Media SDK 2014 для клиентских систем. Загрузить пример можно по следующей ссылке: (https://software.intel.com/sites/default/files/MediaSDK2014Clients.zip.) После установки SDK создается набор переменных среды для поиска правильных путей к файлам заголовков и библиотекам в Visual Studio.

Обзор приложения

Приложение распознает камеру как устройство ввода MJPEG, выполняет декодирование этого видео, затем кодирование потока в формат H264 и, наконец, его декодирование и завершение обработки. Поток видео формата MJPEG с камеры (после декодирования) и полностью обработанные потоки отображаются в графическом интерфейсе на базе MFC. В системах Haswell для обеспечения удобочитаемости выполняется последовательный запуск двух декодеров и одного кодировщика (с разрешением 1080p). Благодаря аппаратному ускорению эта процедура не занимает много времени. Единственным ограничением количества передаваемых кадров в секунду является скорость работы камеры. В реальных условиях кодировщики и декодеры запускаются в отдельных потоках, поэтому проблем с производительностью возникать не должно.

При использовании одного монитора в графическом интерфейсе на базе OpenGL потоковое видео с камеры отображается в режиме «картинка в картинке» поверх обработанного видео (рис. 1). При использовании технологии Miracast программа автоматически определяет монитор с поддержкой Miracast , и на нем во весь экран отображается окно с обработанным видео, при этом в основном графическом интерфейсе отображается необработанное видео с камеры. Такой режим позволяет с легкостью сравнить исходное и кодированное видео. Кроме того, в меню View -> Monitor Topology можно отслеживать текущую топологию мониторов, а также изменять ее. К сожалению, запустить подключение Miracast в этом меню невозможно. Это можно сделать только в меню чудо-кнопок ОС (меню чудо-кнопок справа -> «Устройства» -> «Проект»). На настоящий момент API для запуска подключения Miracast не существует. При этом отключить Miracast-монитор можно, изменив топологию мониторов на «только внутренние». При наличии нескольких мониторов, подключенных с помощью проводов, их топологию можно в любой момент изменить в этом меню.

Рисунок 1. Топология с использованием одного монитора. Видео с камеры MJPEG отображается в правом нижнем углу. Обработанное видео отображается во весь экран. При включении режима использования нескольких мониторов (например, в режиме Miracast) программа обнаруживает данное изменение, в результате чего видео с камеры MJPEG и обработанное видео автоматически выводятся на разные мониторы.

Главная точка входа для настройки процесса обработки

Пример кода выполнен на базе MFC. Главная точка входа для настройки процесса обработки — CChildView::OnCreate (). Здесь выполняется инициализация камеры с последующим транскодированием видео из формата MJPEG в H264, декодированием формата H264 и связыванием текстур из транскодера и декодера в модуле визуализации OpenGL. Транскодер представляет собой подкласс декодера с добавлением кодировщика поверх базового декодера. Событие OnCreate запускает поток, в рамках которого осуществляется и упорядочивается потоковое вещание с камеры. При считывании потокового вещания рабочий поток отправляет сообщение функции OnCamRead, которая выполняет декодирование видео в формате MJPEG, кодирование в формат H264, его декодирование и обновление текстур в модуле визуализации OpenGL. На верхнем уровне весь процесс очень прозрачен и прост.

Инициализация декодера/транскодера

Для использования D3D9Ex необходимо выполнить инициализацию декодера и транс-кодера. Intel® Media SDK может быть настроен на использование программного метода, D3D9 или D3D11. В этом примере для упрощения преобразования цветов используется D3D9. Стандартным цветовым форматом Intel® Media SDK является NV12. Для преобразования цветовой схемы в формат RGBA можно использовать функцию IDirect3DDevice9::StretchRect или функцию IDirectXVideoProcessor::VideoProcessBlt. В целях упрощения в этом техническом документе используется функция StretchRect, однако на практике рекомендуется использовать функцию VideoProcessBlt, так как в нее включена дополнительная возможность последующей обработки. К сожалению, D3D11 не поддерживает StretchRect, что может усложнить процесс преобразования цветов. Кроме того, в этом документе для выполнения различных опытов (таких как сочетание различных типов программного и аппаратного обеспечения) в декодере и транскодере используются отдельные устройства D3D. Однако для экономии ресурсов памяти в декодере и транскодере может использоваться одно устройство D3D. В результате такой настройки процесса обработки результатам, получаемым на выходе после декодирования, задается тип (mfxFrameSurface1 *). Это оболочка для D3D9. Тип mfxFrameSurface1 -> Data. MemId можно преобразовать в тип (IDirect3DSurface9 *). После декодирования этот тип можно использовать в StretchRect или VideoProcessBlt функции CDecodeD3d9::ColorConvert. Полученные поверхности Media SDK нельзя сделать общими, однако преобразование цветов все равно является обязательным в OpenGL. Для хранения результатов преобразования создаются общие поверхности.

Инициализация транскодера

Декодированные транскодером данные направляются непосредственно в кодировщик. Убедитесь, что при выделении поверхностей используется MFX_MEMTYPE_FROM_DECODE.

Связывание текстур в D3D и OpenGL

Код для связывания текстуры можно найти в функции CRenderOpenGL::BindTexture. Убедитесь, что расширение WGLEW_NV_DX_interop определено, затем последовательно используйте функции wglDxOpenDeviceNV, wglDXSetResourceShareHandleNV и wglDXRegisterObjectNV. Поверхность D3D связывается с текстурой OpenGL. Текстуры не обновляются автоматически. Их можно обновить, вызвав функции wglDXLockObjectsNV/wglDXUnlockObjectsNV (CRenderOpenGL::UpdateCamTexture и CRenderOpenGL::UpdateDecoderTexture). После обновления текстуру можно использовать, как любую другую текстуру в OpenGL.

Важные моменты при изменении топологии для нескольких мониторов

Может показаться, что вывести еще одно окно на внешний монитор и управлять им посредством обнаружения изменений в топологии довольно просто. Однако на деле ОС может потребоваться некоторое время для инициализации переключения между режимами, завершения настройки монитора и отображения содержимого. Учитывая использование кодировщика/декодера/D3D/OpenGL и всех сопутствующих компонентов, отладка этого процесса может быть довольно сложным делом. В примере кода при переключении между режимами повторно используется большая часть процедуры, однако более простым вариантом может быть завершение процесса и его повторная инициализация, так как если процесс добавления монитора занимает более 10 секунд, могут возникнуть различные проблемы — даже при подключении с помощью кабелей HDMI или VGA.

Задачи на будущее

Пример кода для этого технического документа написан для D3D9 и не включает поддержку D3D11. Пока трудно с точностью сказать, какой способ преобразования цветовой схемы NV12 в схему RGBA при отсутствии StretchRect или VideoProcessBlt является наиболее эффективным. Документ и пример кода будут обновлены после разрешения вопроса с использованием D3D11.

Благодарности

Выражаем благодарность Петеру Ларссону (Petter Larsson), Михелю Джеронимо (Michel Jeronimo), Томасу Итону (Thomas Eaton) и Петру Биалеки (Piotr Bialecki) за их помощь в создании этого документа.

Intel, эмблема Intel и Xeon являются товарными знаками корпорации Intel в США и в других странах.
*Прочие наименования и товарные знаки могут быть собственностью третьих лиц.
© Корпорация Intel, 2013. Все права защищены.

Линн Томпсон

Download PDF

Виджеты стандартного графического пользовательского интерфейса (GUI) Unity* 3D реагируют на касание так же, как на щелчок мыши c включенной функцией Windows* 8 «Перо и сенсорный ввод». В настоящее время для них невозможно настроить поддержку мультисенсорного ввода и жестов. В этой статье рассказывается о том, как TouchScript расширяет возможности стандартных объектов GUI с помощью функции Pan Gesture. Полученные элементы сохраняют внешний вид и функционал обычных виджетов интерфейса Unity 3D, но при этом поддерживают перетаскивание по экрану (функция Pan Gesture). В приведенном примере Unity 3D работает под управлением ОС Windows 8. Эта платформа обладает множеством средств для создания настраиваемых виджетов графического пользовательского интерфейса.

Создание примера

Пример начинается с создания нескольких сфер и кубов в поле обзора основной камеры сцены. Сцена проста и состоит из нескольких трехмерных объектов, которые можно изменять с помощью стандартных виджетов интерфейса Unity 3D. В основном интерфейс состоит из кнопок, горизонтальных ползунков и переключателей. После настройки каждого виджета мы располагаем в том же месте четырехугольник Unity 3D с аналогичными размерами. В настройках этого четырехугольника мы выбираем функцию TouchScript Pan Gesture, которая дает пользователям возможность перемещать данный объект. При перемещении четырехугольника его координаты присваиваются соответствующему виджету интерфейса Unity 3D. В результате мы получаем стандартный виджет интерфейса Unity 3D, который можно перемещать по экрану с помощью жестов TouchScript Pan Gesture. На рис. 1 показан пример такого интерфейса.

Рисунок 1. Три стандартных виджета графического интерфейса Unity* 3D

Добавление стандартного виджета

Для начала добавим три виджета графического интерфейса с помощью функции OnGUI. Первый виджет состоит из панели и нескольких кнопок, изменяющих масштаб примитивов на сцене. На втором виджете располагаются переключатели, которые присваивают геометрическим объектам фиксированные значения масштаба. Горизонтальные ползунки на третьем виджете вращают объекты на сцене по осям X, Y и Z. Расположим эти виджеты в левой, правой и центральной части верхней области экрана (эти объекты будут размещены с учетом разрешения 1024 x 768).

Существует множество справочных материалов, посвященных настройке стандартных элементов графического интерфейса в Unity 3D. Исходный код этих виджетов можно найти в прилагаемом проекте Unity 3D.

Настройка TouchScript

В данном примере четырехугольники Unity 3D добавляются в качестве целей TouchScript, упрощающих сенсорное управление стандартными виджетами графического интерфейса. Эти примитивы добавляются не через редактор Unity 3D, а программно. Ниже приведен код для создания четырехугольника, перемещающего левый виджет с кнопками:

Public Class:
.
.
.
private GameObject buttonQuad;//Создаем ресурс, обрабатывающий жесты
//Объявляем переменные для обработки жестов, с помощью которых будет изменяться
//стандартное положение GUI
private Vector3 buttonQuadStartPosition;
private float buttonQuadDeltaX;
private float buttonQuadDeltaY;
.
.
.
Start Function:
.
.
//Создаем ресурс, обрабатывающий жесты
buttonQuad = GameObject.CreatePrimitive (PrimitiveType.Quad);

//Приводим вектор положения ресурса в соответствие со стандартным расположением GUI
buttonQuad.transform.position = new Vector3(-0.7f,2.25f,-10.0f);

//Добавляем компоненты TouchScript, чтобы ресурс мог реагировать на сенсорные команды
buttonQuad.AddComponent ("PanGesture");
buttonQuad.AddComponent ("PanScript");

//Задаем начальное положение для ресурса, обрабатывающего сенсорные команды
buttonQuadStartPosition = buttonQuad.transform.position;
//Инициализируем переменные изменения положения
buttonQuadDeltaX = 0.0f;
buttonQuadDeltaY = 0.0f;

//Делаем ресурс для обработки сенсорных команд невидимым
MeshRenderer buttonQuadRenderer = (MeshRenderer) buttonQuad.GetComponent ("MeshRenderer");
buttonQuadRenderer.enabled = false;
.
.
.
Update function:
.
.
//Задаем переменные смены положения. Значение 235 — фактор масштабирования
//для разрешения 1024x768. В полноценном приложении этот фактор будет
//зависеть от разрешения, установленного программой или пользователем.
buttonQuadDeltaX = -235*(buttonQuadStartPosition.x - 	buttonQuad.transform.localPosition.x);
buttonQuadDeltaY = 235*(buttonQuadStartPosition.y - buttonQuad.transform.localPosition.y);
.
.
OnGUI function:
.
.
////////////////////// Меню с кнопками: начало ////////////////////////////////////
//Создаем стандартное окно GUI, расположение которого будет зависеть от положения //ресурса, обрабатывающего команды сенсорного управления
		GUI.Box(new Rect(10+buttonQuadDeltaX,10+buttonQuadDeltaY,240,160), "Button Menu");

//Создаем стандартную кнопку, расположение которой будет зависеть от положения //ресурса, обрабатывающего команды сенсорного управления

		if(GUI.Button(new Rect(20+buttonQuadDeltaX,40+buttonQuadDeltaY,220,20), "Increase Scale (4x Maximum)"))
		{
			//While increasing the cube scale, limit the cube scaling
			//to be between 0.25 and 4

			if (scale < 4.0)
			{
				scale += 0.1f;
				cube01.transform.localScale += (new Vector3(0.1f,0.1f,0.1f));
				cube02.transform.localScale += (new Vector3(0.1f,0.1f,0.1f));
				sphere01.transform.localScale += (new Vector3(0.1f,0.1f,0.1f));
				sphere02.transform.localScale += (new Vector3(0.1f,0.1f,0.1f));

			}
			if (scale == 4.0f)
			{
				maxscale = true;
				minscale = false;
				defaultscale = false;
			}
			else
			{
				maxscale = false;
			}
			if (scale == 0.25f)
			{
				minscale = true;
				maxscale = false;
				defaultscale = false;
			}
			else
			{
				minscale = false;
			}
			if (scale == 1.0f)
			{
				defaultscale = true;
				maxscale = false;
				minscale = false;
			}
			else
			{
				defaultscale = false;
			}
		}

		if(GUI.Button(new Rect(20+buttonQuadDeltaX,80+buttonQuadDeltaY,220,20), "Decrease Scale (0.25x Minimum)"))
		{
			if (scale > 0.25)
			{
			//While decreasing the cube scale, limit the cube scaling
			//to be between 0.25 and 4

				scale -= 0.1f;

				cube01.transform.localScale -= (new Vector3(0.1f,0.1f,0.1f));
				cube02.transform.localScale -= (new Vector3(0.1f,0.1f,0.1f));
				sphere01.transform.localScale -= (new Vector3(0.1f,0.1f,0.1f));
				sphere02.transform.localScale -= (new Vector3(0.1f,0.1f,0.1f));
			}
			if (scale == 4.0f)
			{
				maxscale = true;
				minscale = false;
				defaultscale = false;
			}
			else
			{
				maxscale = false;
			}
			if (scale == 0.25f)
			{
				minscale = true;
				maxscale = false;
				defaultscale = false;
			}
			else
			{
				minscale = false;
			}
			if (scale == 1.0f)
			{
				defaultscale = true;
				maxscale = false;
				minscale = false;
			}
			else
			{
				defaultscale = false;
			}
		}

		//Создаем кнопку для выхода из приложения
		if(GUI.Button(new Rect(20+buttonQuadDeltaX,120+buttonQuadDeltaY,220,20), "Exit Application"))
		{
			Application.Quit();
		}

		GUI.Label (new Rect(20,180,220,20),scale.ToString());
		////////////////////// Меню с кнопками: конец//////////////////////////////////
.
.
.

Сценарий PanScript программно добавляется к четырехугольникам и позволяет сдвигать или перетаскивать их. Работу этих функций можно увидеть в прилагаемом к данной статье примере или в примере под названием Everything, который поставляется вместе с пакетом TouchScript. Прилагаемое видео SGwTS.wmv демонстрирует работу виджетов интерфейса.

Возможности усовершенствования

Самым трудоемким процессом в создании этого примера является размещение четырех-угольника за виджетом GUI. Для этого приходится вручную рассчитывать точные значения x, y, и z и выравнивать положение четырехугольника, совмещая его со стандартным виджетом интерфейса Unity 3D. Кроме того, если пользователь установит разрешение экрана, отличающееся от 1024 x 768, это выравнивание окажется бесполезным. Более совершенным методом будет использование макетов интерфейса и автоматическое размещение четырехугольника с функцией TouchScript Pan Gesture, являющегося целью сенсорной команды.

Ширина четырехугольника в прилагаемом примере совпадает с шириной стандартного виджета графического интерфейса Unity 3D, а высота несколько отличается от него в большую сторону. В результате над виджетом и под ним появляются «поля», с помощью которых пользователь может перемещать виджет по экрану. Передвинув точку сенсорного управления, можно изменить положение четырехугольника относительно стандартного виджета GUI Unity 3D. Например, габариты четырехугольника можно совместить с виджетом внизу и по бокам, тем самым переместив предполагаемую точку управления в верхнюю часть виджета.

В приведенном примере пользователь может перемещать четырехугольник и связанный с ним виджет за любую точку (даже если она находится в габаритах виджета). Чтобы сделать активными только те области, которые выходят за пределы виджета, можно добавить еще один «блокирующий» четырехугольник. Размеры и положение этого четырехугольника должны совпадать с габаритами стандартного виджета графического интерфейса Unity 3D. Размещение блокирующего четырехугольника будет определяться другим четырехугольником, который изменяет положение стандартного виджета. Сама блокировка производится с помощью функции поведения TouchScript Untouchable. Такое поведения можно увидеть в примере Hit. Также это поможет избежать ошибки, при которой ползунок виджета двигется, когда передвигается горизонтальный ползунок.

С помощью сочетания блокирующих и активных четырехугольников можно добиться перемещения настраиваемых виджетов. В совокупности эти два вида четырехугольников позволяют перемещать отдельные компоненты графического интерфейса без изменения позиции самого виджета. Например, пользователь сможет по отдельности независимо перемещать горизонтальные ползунки, находящиеся на одной неподвижной базе. Также с помощью настраива¬емой функции Pan Gesture можно ограничить перемещение компонентов виджета рамками самого элемента интерфейса.

Порядок касания

Напомним, что один из настроенных нами виджетов GUI позволяет масштабировать геометрические примитивы, расположенные на сцене. Левый куб и правую сферу можно свободно перемещать по сцене, так как они были настроены с помощью функции Pan Gesture. В то же время куб и сфера, расположенные в центре сцены, не связаны с TouchScript и не реагируют на сенсорное управление. Из-за этого масштабируемые примитивы могут закрыть собой четырехугольники, предназначенные для перемещения виджетов интер¬фейса. Если пользователь увеличит размер примитива, а затем перетащит на него виджет, следующая сенсорная команда в этой области экрана затронет не виджет, а примитив. Разумеется, можно использовать ту же команду-жест, чтобы вывести примитив из области виджета и снова сделать этот элемент интерфейса доступным для сенсорного управления.

Тем не менее, если пользователь перетащит виджет на один из центральных примитивов, которые не поддерживают сенсорное управление, этот виджет будет заблокирован. Эту проблему можно решить, назначив через TouchScript примитиву поведение Untouchable с помощью кнопки Add Component («Добавить компонент») (см. рис. 2). Такая конфигурация позволит виджетам GUI, настроенным с помощью функции Pan Gesture, считывать сенсорные команды даже через геометрические примитивы. Эту схему можно наблюдать в прилагаемом видео: при перемещении виджета интерфейса на левый куб или правую сферу следующий жест передвигает соответствующий примитив. В то же время после переноса виджета на среднюю сферу (которой назначено поведение Untouchable) следующая команда перемещает сам виджет. Если из-за фактора масштабирования средний куб закроет собой не прошедшие рендеринг четырехугольники, перенесенный на этот куб виджет окажется заблокированным.

Во всех случаях, когда один из ресурсов сцены может помешать элементу интерфейса, следует назначить этому элементу поведение Untouchable. Для шутеров от первого лица (FPS), в которых используются виджеты интерфейса, описанные в этой статье, следует настраивать в TouchScript поведение Untouchable для каждого ресурса, с которым может войти в контакт главная камера.

Рисунок 2. Настройка сенсорного управления для объектов, находящихся за ресурсом Unity* 3D

Последовательность рендеринга

Видимые компоненты виджетов GUI, упоминающихся в этой статье, созданы с помощью встроенной функции Unity 3D OnGUI. Они будут отображаться всегда, и настраивать отдельную камеру для рендеринга отдельного слоя виджетов не требуется.

Заключение

Функции пакета TouchScript хорошо подходят для совместной работы со стандартными интерфейсными виджетами Unity 3D. Сочетание этих функций позволяет создавать традиционные элементы интерфейса, которые можно перемещать по экрану с помощью стандартного управления. При этом нет необходимости разрабатывать виджеты с нуля и создавать геометрические объекты для работы с жестами TouchScript. Полученный в результате код отличается стабильностью работы на платформе Unity 3D для Windows 8. Описанный метод идеально подходит для быстрой разработки стандартных виджетов графического интерфейса с поддержкой перетаскивания.

Другие материалы по этой теме:

• How To Plan Optimizations with Unity*
• Implementing Multiple Touch Gestures Using Unity* 3D with TouchScript
• Unity* 3D Touch GUI Widgets
• Adding Multi-Touch Support to Unity* Games on Microsoft Windows* 7 and Windows* 8 Desktop
• Using Intel Perceptual Computing SDK in the Unity 3D Environment

Об авторе

Линн Томпсон — специалист в области ИТ, более 20 лет проработавший в области компьютеризации предпринимательской и производственной сферы. Одной из первых его работ стало использование САПР для создания и редактирования чертежей контрольных приборов для энергосистем. Тогда же он получил степень бакалавра электротехники в Университете Небраски (г. Линкольн). В эпоху бума доткомов Линн занимался системным администрированием операционных систем, баз данных и приложений на различных платформах в одном из ИТ-интеграторов. Позже, после «краха доткомов», он участвовал во множестве проектов в роли ИТ-консультанта. Линн работал с компаниями, работающими в сфере легкой промышленности, а также нефтегазовой и оборонной индустрии. Сейчас он вновь вернулся к своей специальности и работает инженером-энергетиком. Линн получил магистерскую степень инженера со специализацией в области управления техническими системами (также в Университете Небраски).

Intel, эмблема Intel и Xeon являются товарными знаками корпорации Intel в США и в других странах.
*Прочие наименования и товарные знаки могут быть собственностью третьих лиц.
© Корпорация Intel, 2013. Все права защищены.

Download PDF

Линн Томпсон

Если вы настраиваете цели касания, которые управляют элементами на сцене, важно уменьшить область управления, насколько это возможно. Так вы сможете максимально расширить область экрана на устройстве Ultrabook™, предназначенную для отображения привлекательного контента. Для этого можно настроить цели касания так, чтобы они обрабатывали различные комбинации жестов. Таким образом, количество целей касания на экране сократится до минимума. Например, два элемента интерфейса, один из которых заставляет пушку стрелять, а второй — вращаться, можно заменить на один, позволяющий выполнять оба действия одним непрерывным касанием.

В этой статье я расскажу о том, как настроить сцену для управления контроллером от первого лица при помощи целей касания. Прежде всего необходимо настроить цели касания для базовой позиции контроллера и вращения, а затем расширить набор их функций. Послед¬него можно достичь за счет существующих элементов интерфейса, не добавляя новые объекты. Сцена, которая у нас получится, продемонстрирует широкие возможности Unity 3D в ОС Windows* 8 как платформы для обработки различных последовательностей жестов.

Настройка сцены в Unity* 3D

Для начала необходимо настроить сцену. Для этого импортируем в Unity* 3D ресурс ландшафта в формате .fbx с горами и деревьями, экспортированный из Autodesk 3D Studio Max*. Поместим контроллер в центре ландшафта.

Установим показатель глубины основной камеры (она входит в состав контроллера) на уровень -1. Создадим отдельный элемент интерфейса камеры с поддержкой ортогональной проекции, шириной 1 и высотой 0,5, а также флагами Don’t Clear. Затем создадим слой GUIWidget и сделаем его маской интерфейса камеры.

Расположим основные элементы интерфейса, управляющие контроллером, на сцене в поле обзора ортогональной камеры. Добавим сферу для каждого пальца левой руки. Сфера мизинца заставляет контроллер двигаться влево, сфера безымянного пальца — вперед, среднего пальца — вправо, а указательного пальца — назад. Сфера большого пальца позво-ляет прыгать и запускать сферические снаряды под углом 30 градусов по часовой стрелке.

Для элемента интерфейса правой руки создадим куб (квадрат в ортогональной проекции). Настроим для этого куба поддержку жеста сдвига и привяжем его к скрипту MouseLook.cs. Этот элемент интерфейса обеспечивает такие же возможности, как и сенсорная панель устройства Ultrabook.

Эти элементы интерфейса расположим вне поля обзора основной камеры, а в качестве слоя установим GUIWidget. На рис. 1 можно увидеть, как элементы интерфейса позволяют запускать снаряды и управлять позицией контроллера на сцене.

Рисунок 1. Сцена контроллера от первого лица с ландшафтом и запущенными сферическими снарядами.

На этой сцене снаряды, запущенные из контроллера, пролетают сквозь деревья. Чтобы это исправить, необходимо добавить сетку или коллайдер к каждому дереву. Другая проблема на этой сцене — низкая скорость движения вперед — возникает при попытке посмотреть вниз с помощью сенсорной панели одновременно с движением вперед с помощью сферы безымянного пальца. Чтобы устранить эту неполадку, можно ограничить угол обзора при взгляде вниз, когда удерживается кнопка движения вперед.

Множественные касания

На базовой сцене находится контроллер от первого лица, который запускает снаряды под определенным углом по направлению от центра (см. Рисунок 1). По умолчанию установлен угол в 30 градусов по часовой стрелке.

Настроим сцену для поддержки множественных касаний, выполняемых чаще, чем установленный период, изменим угол запуска снарядов и попробуем запустить снаряд. В этом случае можно настроить угол на возрастание в геометрической прогрессии в зависимости от числа касаний при помощи переменных типа float в скрипте для сферы большого пальца слева. Эти переменные регулируют угол и время с момента запуска последнего снаряда:

	private float timeSinceFire = 0.0f;
	private float firingAngle = 30.0f;

Далее настроим цикл Update в скрипте для сферы большого пальца так, чтобы угол запуска снарядов снижался, если касания сферы большого пальца выполняются чаще, чем раз в полсекунды. В том случае, если касания последуют реже, чем раз в полсекунды, или угол запуска снарядов снизится до 0 градусов, величина угла запуска снарядов вернется к показателю 30 градусов. Получится следующий код:

		timeSinceFire += Time.deltaTime;

			if(timeSinceFire <= 0.5f)
			{
				firingAngle += -1.0f;

			}
			else
			{
				firingAngle = 30.0f;
			}

			timeSinceFire = 0.0f;

			if(firingAngle <= 0)
			{
				firingAngle = 30;
			}


			projectileSpawnRotation = Quaternion.AngleAxis(firingAngle,CH.transform.up);

Такой код произведет эффект обстрела, при котором непрерывные касания приведут к запуску снарядов под постоянно уменьшающимся углом (см. рис. 2). Этот эффект можно позволить настраивать пользователям либо сделать доступным при соблюдении определенных условий в игре или режиме симуляции.

Рисунок 2. Непрерывные касания приводят к изменению направления запуска снарядов.

Масштабирование прокруткой

Мы настроили квадрат в правой нижней части экрана на рис. 1 на работу в режиме, аналогичном сенсорной панели на клавиатуре. При жесте сдвига квадрат не двигается, а поворачивает основную камеру сцены вверх, вниз, влево и вправо с помощью скрипта контроллера MouseLook. Аналогичным образом жест масштабирования (схожий со растягиванием/сжатием на других платформах) приводит не к масштабированию квадрата, а к изменению поля зрения основной камеры, благодаря которому пользователь может приблизить или отдалить объект на основной камере (см. Рисунок 3). Настроим контроллер таким образом, чтобы жест сдвига сразу после масштабирования возвращал поле зрения камеры к значению по умолчанию 60 градусов.

Для этого нужно запрограммировать логическую переменную (panned) и переменную типа float, чтобы они отмечали время, прошедшее от последнего жеста масштабирования:

	private float timeSinceScale;
	private float timeSincePan;
	private bool panned;

Установим для переменной timeSinceScale значение 0.0f при выполнении жеста масштабирования, а для переменной panned — значение True при выполнении жеста сдвига. Поле зрения основной камеры сцены настраивается в цикле Update, как можно увидеть в скрипте для прямоугольника-сенсорной панели:

		timeSinceScale += Time.deltaTime;
		timeSincePan += Time.deltaTime;

		if(panned && timeSinceScale >= 0.5f && timeSincePan >= 0.5f)
		{
			fieldOfView += 5.0f;
			panned = false;
		}

		if(panned && timeSinceScale <= 0.5f)
		{
			fieldOfView = 60.0f;
			panned = false;
		}

		Camera.main.fieldOfView = fieldOfView;

Установим для переменной timeSinceScale значение 0.0f при выполнении жеста масштабирования, а для переменной panned — значение True при выполнении жеста сдвига. Поле зрения основной камеры сцены настраивается в цикле Update, как можно увидеть в скрипте для прямоугольника-сенсорной панели:

	private void onPanStateChanged(object sender, GestureStateChangeEventArgs e)
    {
        switch (e.State)
        {
            case Gesture.GestureState.Began:
            case Gesture.GestureState.Changed:
                var target = sender as PanGesture;
                Debug.DrawRay(transform.position, target.WorldTransformPlane.normal);
                Debug.DrawRay(transform.position, target.WorldDeltaPosition.normalized);

                var local = new Vector3(transform.InverseTransformDirection(target.WorldDeltaPosition).x, transform.InverseTransformDirection(target.WorldDeltaPosition).y, 0);
                targetPan += transform.InverseTransformDirection(transform.TransformDirection(local));

                //if (transform.InverseTransformDirection(transform.parent.TransformDirection(targetPan - startPos)).y < 0) targetPan = startPos;
                timeSincePan = 0.0f;
				panned = true;
				break;

        }

    }

	private void onScaleStateChanged(object sender, GestureStateChangeEventArgs e)
    {
        switch (e.State)
        {
            case Gesture.GestureState.Began:
            case Gesture.GestureState.Changed:
                var gesture = (ScaleGesture)sender;

                if (Math.Abs(gesture.LocalDeltaScale) > 0.01 )
                {
					fieldOfView *= gesture.LocalDeltaScale;

					if(fieldOfView >= 170){fieldOfView = 170;}
					if(fieldOfView <= 1){fieldOfView = 1;}

					timeSinceScale = 0.0f;


                }
                break;
        }
    }

Рисунок 3. Основная камера сцены с изображением, приближенным при помощи прямоугольника сенсорной панели справа

Нажатие, отпускание с щелчком

Если нажать и отпустить сферу мизинца, а затем в течение полсекунды провести по ней, можно увеличить горизонтальную скорость контроллера.

Для поддержки этой функции добавим переменную типа float и логическую переменную, которые позволят отмечать время с жестов отпускания сферы мизинца и жеста щелчка по ней:

	private float timeSinceRelease;
	private bool flicked;

При первоначальной установке сцены я предоставил скрипту сферы мизинца доступ к скрипту контроллера InputController, чтобы сфера мизинца слева могла заставлять контроллер двигаться влево. Переменная, управляющая горизонтальной скоростью контроллера, находится не в скрипте InputController, а в скрипте CharacterMotor. Передать скрипт сферы левого мизинца скрипту CharacterMotor можно аналогичным образом:

		CH = GameObject.Find("First Person Controller");
		CHFPSInputController = (FPSInputController)CH.GetComponent("FPSInputController");
		CHCharacterMotor = (CharacterMotor)CH.GetComponent ("CharacterMotor");

Функция onFlick в нашем скрипте лишь позволяет установить для логической переменной flicked значение, равное True.

Функция Update в скрипте вызывается один раз за кадр и изменяет движение контроллера по горизонтали следующим образом:

		if(flicked && timeSinceRelease <= 0.5f)
		{
			CHCharacterMotor.movement.maxSidewaysSpeed += 2.0f;
			flicked = false;
		}

		timeSinceRelease += Time.deltaTime;
	}

Благодаря этому коду можно увеличивать скорость движения по горизонтали. Для этого нужно нажать и отпустить сферу мизинца, а затем провести по ней в течение полсекунды. Настроить замедление движения по горизонтали можно различными способами. Например, для этого можно использовать нажатие и отпускание сферы указательного пальца, а затем щелчок по ней. Обратите внимание на то, что способ CHCharacterMotor.movement содержит не только параметр maxSidewaysSpeed, но также gravity, maxForwardsSpeed, maxBackwardsSpeed, и другие. Использование разнообразных жестов библиотеки TouchScript и объектов, которые обрабатывают жесты, в сочетании с этими параметрами обеспечивает широкие возможности и различные стратегии разработки сенсорных интерфейсов в сценах Unity 3D. При создании сенсорных интерфейсов для таких приложений можно пробовать различные варианты и выбирать наиболее эффективные и эргономичные.

Проблемы с последовательностями жестов

Последовательности жестов, которые мы использовали в этой статье, существенно зависят от функции Time.deltaTime. Я применяю эту функцию в сочетании с разными жестами до и после того, как функция определит действие. Две основные проблемы, с которыми я столкнулся при настройке этих случаев, заключаются в величине временного интервала и характере жестов.

Временной интервал

При написании этой статьи я использовал интервал в полсекунды. Если я выбирал интервал равный одной десятой секунды, устройство не могло распознать последовательности жестов. Хотя мне казалось, что темп касаний был достаточно высок, это не приводило к нужным действиям на экране. Возможно, это связано с задержками в работе устройства и ПО, поэтому рекомендую при разработке последовательностей жестов учитывать производительность целевой платформы.

Жесты

При работе над этим примером я изначально собирался использовать жесты масштаби-рования и сдвига, а затем касания и щелчка. Масштабирование и сдвиг работали правильно, но перестали, как только я добавил жест касания. Хотя мне удалось настроить последовательности из жестов масштабирования и сдвига, она не очень удобна для пользователя. Более удачным вариантом будет настроить другую цель касания в элементе интерфейса на обработку жестов касания и проведения после масштабирования и сдвига.

В этом примере я использую интервал времени в полсекунды, чтобы определять, выпол-нено действие или нет. Также можно настроить несколько временных интервалов, хотя это и приведет к усложнению интерфейса. Например, последовательность жестов нажатия и отпускания и следующего в течение полсекунды за ними проведения может увеличивать скорость движения по горизонтали, а аналогичная последовательность с интервалом от полсекунды до секунды — снижать скорость. Используя временные интервалы таким образом, можно не только более гибко настроить пользовательский интерфейс, но и добавить на сцену скрытые секреты.

Заключение

В этой статье я настроил сцену с различными последовательностями жестов в Unity* 3D с помощью библиотеки TouchScript на устройстве Ultrabook с ОС Windows 8. Цель реализа-ции этих последовательностей — сократить область экрана, с помощью которой пользова-тель управляет приложением. В этом случае можно выделить большую площадь экрана для показа привлекательного контента.

В тех случаях, когда последовательности жестов не работали правильно, нам удавалось найти подходящее альтернативное решение. Одной из задач настройки было добиться правильной работы последовательности действий с помощью функции Time.deltaTime на имеющемся устройстве. Таким образом, сцена, которую мы создали в Unity 3D для этой статьи, подтверждает жизнеспособность ОС Windows 8 на устройствах Ultrabook как платформы для разработки приложений с использованием последовательностей жестов.

Другие материалы по данной теме

• How To Plan Optimizations with Unity*
• Implementing Multiple Touch Gestures Using Unity* 3D with TouchScript
• Unity* 3D Touch GUI Widgets
• Adding Multi-Touch Support to Unity* Games on Microsoft Windows* 7 and Windows* 8 Desktop
• Using Intel Perceptual Computing SDK in the Unity 3D Environment
• Using Unity* 3D Standard GUI with TouchScript Assets

Об авторе

Линн Томпсон — специалист в области ИТ, более 20 лет проработавший в области компьютеризации предпринимательской и производственной сферы. Одной из первых его работ стало использование САПР для создания и редактирования чертежей контрольных приборов для энергосистем. Тогда же он получил степень бакалавра электротехники в Университете Небраски (г. Линкольн). В эпоху бума доткомов Линн занимался системным администрированием операционных систем, баз данных и приложений на различных платформах в одном из ИТ-интеграторов. Позже, после «краха доткомов», он участвовал во множестве проектов в роли ИТ-консультанта. Линн сотрудничал с компаниями, работающими в легкой промышленности, а также нефтегазовой и оборонной индустрии. Сейчас он вернулся к своей специальности и работает инженером-энергетиком. Линн получил магистерскую степень инженера со специализацией в области управления техническими системами (также в Университете Небраски).

Intel, эмблема Intel, Ultrabook и VTune являются товарными знаками корпорации Intel в США и в других странах.
*Прочие наименования и товарные знаки могут быть собственностью третьих лиц
© Корпорация Intel, 2014. Все права защищены.