I am using cooperative_groups::thread_blocks for the first time, and I'm a bit lost. I would like to have code where I can decide on the cooperative_groups::thread_block_tile size at runtime, however this doesn't seem to be possible with the thread_block_tile since you need to pass the size to the template at compile time. I see you can also use the method tiled_partition without a template to get a thread_block instead of a thread_block_tile, however, the ballot and shfl methods don't work and I seem to instead need to use __ballot_sync and __shfl_sync. However these methods require a mask, and I'm not quite clear on how this works. Would calling activemask() work to do a ballot within a single thread_block, or would you have to get a mask in some other way. Or is there some way to get variably sized thread_block_tile's that I'm missing?
Related
I am now using ITK library to image registration. I wonder, when setting initial parameters for ImageRegistrationMethodv4 type registration, shall I use SetMovingInitialTransform and SetFixedInitialTransform like in the tutorial, or just SetInitialTransform??
The "transform" in SetInitialTransform means transform for moving image or for fixed image? Thank you:)
(Please read this with caution--I do not have the library with me to test this answer; it's based on memory only.)
I believe SetInitialTransform() refers to the transform which is actually optimized by the registration method. In other words, it is a collection of transform parameters that specify an "initial guess" for the optimization process; these parameters will then start moving around at each iteration. (They are therefore applied to the moving image.)
I think SetMovingInitialTransform() and SetFixedInitialTransform() refer to static initial transforms which do no change at all during the registration process. They merely "set up" the moving and fixed images to desired starting locations, if you are not satisfied with their default positions in space.
If you have some simple 2D images, try testing this answer out with simple initial transformations, like a 5-unit translation transformation or something.
You could try reading the ImageRegistrationMethov4 documentation for a little more info.
What invalidateProperties(), invalidateSize() and invalidateDisplayList() methods are did when extending a component in adobe flex/air ?.
And why these are necessary?
As per the documentation, these functions signal flex/flash to call another function before updating and rendering the display list. This "other function" seems to be for validation (and possibly altering the values if they're incorrect). So by calling an invalidate function, you force a recalculation. Or, in other words, a redraw. This removes any left over graphical artifacts.
That's my explanation via the documentation. Perhaps someone with more experience can build upon my answer.
All these components are based upon the RENDER event so no matter how many changes they go through (ex: x, y, width, etc ...) they are drawn only once per frame. But to get the RENDER event to trigger for each component a stage.invalidate() must be called and parsed on a per component basis. All the component invalidate methods allow you to force a redrawing of the component by skying the RENDER event step or in other cases by starting the RENDER event workflow.
I'm unclear on how memory works in Actionscript 3. I create a series of buttons and store the address to each of them in an array. Those buttons are used to play various music files, and I want the one that is playing to have a particular color (red) and the rest to be white. I call the following code when the currently selected button is to be replaced by a different button:
removeChild(songSelectButton[currSong]);
var songSelWhite:Button = new Button(null, "images/TrackButtonNo.jpg", TRACK_SELECT_WIDTH, TRACK_SELECT_HEIGHT);
songSelectButton[currSong] = songSelWhite;
That allows the array to have the right buttons. However, I am concerned about whether I am wasting memory. Does garbage collection take care of this, or do I need a better approach?
In most cases, garbage collection is pretty smart and can clean up whatever mess you make. But it can take its time getting around to it, and it can really tie up the CPU when it decides to do it's thing. So careful management of memory is valuable.
In your case, why create a new Button? You've got a Button already, and it looks like its already in the right spot and everything. Just change the image, any listeners, and any other properties that you really need to change. Then you won't have to worry about new buttons getting allocated and deallocated, and you won't even have to worry about a new layout being calculated.
I need to render some points with specified size using ShapeRenderer.
When using GL20, Gdx.gl and Gdx.gl20 will be initialized, while Gdx.gl10 and Gdx.gl11 will be null.
I can set line width and render using code such as this:
Gdx.gl.glLineWidth(5);
mShapeRenderer.begin(ShapeType.Rectangle);
mShapeRenderer.rect(0.0f, 0.0f, 50.0f, 50.0f);
mShapeRenderer.end();
But, from what I figured out, I can only set point size using Gdx.gl10.glPointSize(5) or Gdx.gl11.glPointSize(5) - which won't work in my case since both gl10 and gl11 are null.
Are there any simple solutions to this problem?
OpenGL ES dropped support for glPointSize (among other things) in 2.0, that's why you can't find it in Gdx.gl20, or in Gdx.gl.
Instead of setting a point size, just use ShapeRenderer's filledCircle to render the "large" points. (I would point to the API documentation, but they just changed the API last week and I'm not sure which version you are using.)
I have an application that switched between different graphs in Flex. Each graph is it's own state. In the MXML I have it set so that the source of the image change when the state changes:
<s:Image id="chartImage"
source.all="{ callImages.all }"
source.classA="{ callImages.classB }"
source.classB="{ callImages.classA }"
/>
I have buttons that successfully change the images. However, I have a small bug which occurs because after the line
this.currentState = chartName;
My code expected the graph image source to be changed, however the actual change to the s:Image element doesn't appear to happen until after the function ends and the screen updates, I assume. So when it grabs chartImage.height, it uses the old one from the state I just left.
Is there a way to have it get the new image (and thus it's dimensions) so I can do calculations with those dimensions on the next line? So far, chartImage.height returns the height from before the state change, but it is different after the function executes.
I could run a timmer after a fraction of a second then execute the lines there, and it would work. However, I'd rather tell it to render the screen and then continue my code. Is this possible? It just seems more elegant.
Is there a way to have it get the new image (and thus it's dimensions)
so I can do calculations with those dimensions on the next line?
Each Flex component must go through it's own validation cycle, which is built on top of the Flash Player's rendering mechanism. There are some great posts out on this, if you perform a Google search for the Flash/Flex Elastic Racetrack.
However, you can force a component to run through it's validation methods in a linear manner by calling the validateNow() method.
It is possible--especially if you have a state transition--that the properties on your Image have not changed yet after you set the currentState variable.
You generally can't change the source of an image in Flex and then immediately check ("on the next line") it's height — the exception might be when the source is a raw bitmap, but even then Flex's layout framework will vary depending on different factors so I wouldn't rely on this.
This is the classic problem with Flex: the beauty (and misery) of the framework is that it progressively renders it's changes to maximize the responsiveness of the app. Google "flex component life cycle" for a ton of resources about the details of this process.
There are a couple of ways to deal with this. Usually you'll want to use binding expressions, since they are designed for exactly this reason: asynchronous layout changes. Don't overuse them but they are a solid tool to keep the codebase simple and flexible.
You can bind to the height of a SparkImage via mxml:
<s:Image id="chartImage" />
<s:Label id="debugLabel" text="{ 'Height of chartImage: ' + chartImage.height }" />
but if you need to run logic I'd recommend using the BindingUtils (in the script block):
import mx.binding.utils.BindingUtils;
protected function someOtherFunctionBlock():void
{
BindingUtils.bindSetter( handleHeigtChange, image, "height" );
}
protected function handleHeigtChange( value:Number ):void
{
// Deal with value change
}