Using Arc, I have a CgImageRef as a property of an object (Shape). Ultimately I will assign the CgImageRef to the contents of 1 or more layers but initially I just keep it in the shape. Things work fine if I do this:
CgImageRef cgImageRef = CGImageCreateWithImageInRect(....);
someLayer.contents = (__bridge id)cgImageRef;
CFRelease(cgImageRef);
but if I say
myShape.cgImageRef = CGImageCreateWithImageInRect(...);
the analyzer reports a potential memory leak.
I tried, within the ShapeObject, adding a dealloc method that uses CFRelease on the cgImageRef, but then the analyzer says that I am releasing an object I do not own.
Bridging does not seem to apply since I'm not assigning the pointer to another object. What exactly am I supposed to do here?
Related
I would like to add 3D object in Windows 10 UWP map control.
This object would be "polygon with height", e.g. simple representation of a house - cuboid or cube.
Illustration image:
I know that I can add Xaml control (and inside it 3D object e.g. Cube) but then this Cube is not 'map object', only pinned to a certain Lat/Lon.
Any idea how to implement this?
Microsoft has added MapElement3D in Windows 10 Insider Preview v10.0.16257.0. - that's the falls creators update. It allows you to add objects, turn them, control their size, and direction. You can make them move too!
Example
How-To
Represents a 3D element displayed on a MapControl.
It's usage appears to be very similar to other MapElements, such as MapIcons and MapBillboards.
map3dSphereStreamReference = RandomAccessStreamReference.CreateFromUri
(new Uri("ms-appx:///Assets/trainengine.3mf"));
var myModel = await MapModel3D.CreateFrom3MFAsync(map3dSphereStreamReference,
MapModel3DShadingOption.Smooth);
var my3DElement = new MapElement3D();
my3DElement.Location = myMap.Center;
my3DElement.Model = myModel;
myMap.MapElements.Add(my3DElement);
Beware of two undocumented issues:
Attempting to add the same 3DMapElement to two different MapControls will result in System.AccessViolationException. This can happen if you cached the 3D model but not the page with the map control.
HResult=-2147467261 Message=Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.
Attempting to call MapModel3D.CreateFrom3MFAsync() from a non-Ui thread will cause a crash. This must be called from a UI thread.
I try to code an OpenGL project with Qt (v5.1.1) on OS X 10.9, in the manner of the modern pipeline implementation. The program is supposed to be a multi-agent based system or particle system. However I lack in understanding how to draw something out of another class.
In cinder there were some simple drawThisAndThat() command you could call. I read the 6th edition of the 'OpenGL Superbible'. From this and several tutorials all examples seem to cover just programs where all modifications are made out of the class that initializes OpenGL.
I would like to instantiate some objects moving on a grid and draw pixel to display their position. I know I have to call void glVertexAttrib4fv(GLuint index, const GLfloat * vi); but this is not sufficient.
Do I need to call glEnableVertexAttribArray(1); and glDrawArrays(GL_POINTS, 0, 3); as well and what else?
Am I right, to instantiate the class controlling the particles after instantiating OpenGL and bevor the main loop?
How do I manage that the particle draws himself while erasing the position he was drawn bevor?
The program is based on this code.
To answer your questions completely I would have to write a wall of text, I will try to only point out the most important aspects. I hope this will help you enough to use your knowledge and probably further reading to get it to work.
all modifications are made out of the class that initializes OpenGL
You can encapsulate update(time) and draw() methods for your Objects which you then call in your main loop.
Do I need to call glEnableVertexAttribArray(1); and glDrawArrays(GL_POINTS, 0, 3); as well and what else?
I would put all particles into one vertex array to avoid rebinding of different vertex arrays after each particle. Then you would have to use glBindVertexArray(vaid); and glDrawArrays(GL_POINTS, 0, vertexCount); in your draw() call. Be careful with vertexCount, it's not the number of floats (as your question implies) but the number of vertices, which should be 1 in your example or the number of particles in my suggested approach (If I'm correct in assuming that the 3 stands for "x, y, and z of my vertex").
And since you only have particles glDrawElements(...); would probably already fit your needs.
Am I right, to instantiate the class controlling the particles after instantiating OpenGL and bevor the main loop?
Probably your instantiation order is correct that way. You definitely should do all instantiations before calling the main loop in your case.
How do I manage that the particle draws himself while erasing the position he was drawn bevor?
If understand your last question correctly: Simply by changing the elements in your buffer objects (glBufferData(...);). Since you will clear the screen and swap buffers after each loop this will make them move. Just update their position with an update(time) call, e.g. pos = pos + dir * time;, put the new positions into a buffer and push that buffer with glBufferData(...) to the vertex array. Remember to bind the vertex array before pushing the buffer.
Some additional things I'd like to point out.
glEnableVertexAttribArray(1); is to enable a vertex attribute in your shader program to be able to pass data to that attribute. You should create a shader program
id = glCreateProgram()
// ... create and attach shaders here
// then bind attribute locations, e.g. positionMC
glBindAttribLocation(id, 0, "positionMC");
glLinkProgram(id);
And after initializing the vertex array with glGenVertexArrays(); you should enable all attributes your vertex array needs in your shader program. In this example positionMC would be at location 0, so you would call something like
glUseProgram(pid);
glBindVertexArray(vaid);
glEnableVertexAttribArray(1);
glVertexAttribPointer(...);
This has only to be done once, since OpenGL stores the state for every particular vertex array. By rebinding a vertex array you will restore that state.
In the main loop all you have to do now is calling your update and draw methods, e.g.:
handleInputs();
update(deltaTime);
glClear(...);
draw();
swapBuffers();
Let's say that I have a canvas component called myCanvas and I instantiated it with
var myCanvasPage:myCanvas = new myCanvas;
this.addChild(myCanvasPage);
Then I want to essentially reload myCanvasPage later on. In effect I want to do this:
this.removeChild(myCanvasPage);
var myCanvasPage:myCanvas = new myCanvas;
this.addChild(myCanvasPage);
except instead of creating a new instance of myCanvas, I want to use the already created instance of myCanvas and essentially reload or re-create it but making sure that the instance name and references to it remain the same. What would be the best way to do this?
Whenever you do
var myCanvasPage:myCanvas = new myCanvas;
you are instantiating the myCanvasPage Object.
Removing an object from the stage will not delete the Object from memory.
As long as there is a reference somewhere in your code the myCanvasPage Object will not be garbage collected and all the values and attributes will be the same as at the time you removed it from the stage.
To make that reference you have to scope it to your class.
public var myCanvasPage:myCanvas = new myCanvas;
So now you would reference it with
this.myCanvasPage
and when you are ready to add it back to the stage.
this.addChild(this.myCanvasPage);
So to recap you can add and remove an Object from stage
this.addChild(this.myCanvasPage);
this.removeChild(this.myCanvasPage);
all day long and the data in that object will never go away.
Some good reading on garbage collection
What do you mean as "reloading"? Maybe it is simpler to create data-driven components and change that data to change or reset component state>
Woa I'm not sure where to start here... I think THE_asMan addresses most of your misunderstandings. The missing bit I think you need to look into is how a reference to an object holds (i.e. is counted) as long as it doesn't go out of scope. Just keep in mind that as long as the a variable is not out of scope, its reference to some object (if there is one, i.e. if it is not null) is counted.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9d.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f8c
Hopefully this isn't too stupid but I want to make sure I'm doing this right.
Some Qt functions return Qt objects as values, but we may want to store them in a pointer somewhere. For example, in QDomDocument, the function documentElement returns a QDomElement, not a pointer to it. Now, as a member of my class I have:
QDomElement *listRootElement;
In a function that sets things up I am using this:
listRootElement = new QDomElement;
*listRootElement = mainIndex->documentElement();
(mainIndex is a QDomDocument.)
This seems to work, but I just want to make sure I'm doing it right and that nothing will come back to bite me.
It would be very similar for some of the image functions where a QPixmap might be returned, and I want to maintain pointers to QPixMap's.
Thanks for any comments!
Assuming that you want to store a pointer to a QDomElement for some reason, and assuming that you aware of the potential pitfalls with pointers (like, two pointers might point to the same object):
The only thing to keep in mind is that the popular 'parent takes care of deleting children' system which Qt uses is only available for QObject (sub-)classes. So when new'ing a QString or a QDomElement or something like that, keep in mind that you do have to delete it yourself, too.
I'm guessing, but I think this:
listRootElement = new QDomElement(mainIndex->documentElement());
...may allow the compiler to optimise better (see this question for some reasoning).
You're overwriting the initially allocated object:
QDomElement *listRootElement; // undefined ptr value, I'd prefer null or new right away
listRootElement = new QDomElement;
*listRootElement = mainIndex->documentElement();
You're essentially doing:
int *x = new int(42);
*x = 47;
This works because both QDomElement and int implements the assignment operator (=).
Note that there's no need to delete anything, as the returned temporary is copied into your newly allocated object.
I'm working on reducing the memory requirements of my AS3 app. I understand that once there are no remaining references to an object, it is flagged as being a candidate for garbage collection.
Is it even worth it to try to remove references to Loaders that are no longer actively in use? My first thought is that it is not worth it.
Here's why:
My Sprites need perpetual references to the Bitmaps they display (since the Sprites are always visible in my app). So, the Bitmaps cannot be garbage collected. The Bitmaps rely upon BitmapData objects for their data, so we can't get rid of them. (Up until this point it's all pretty straightforward).
Here's where I'm unsure of what's going on:
Does a BitmapData have a reference to the data loaded by the Loader? In other words, is BitmapData essentially just a wrapper that has a reference to loader.content, or is the data copied from loader.content to BitmapData?
If a reference is maintained, then I don't get anything by garbage collecting my loaders...
Thoughts?
Using AMF a bit with third party products has lead me to believe the Loader class attempts to instantiate a new class of the given content type (in this case it would be a Bitmap class instance). You are probably constructing a new BitmapData object from your Bitmap instance. From that I would assume that the Loader instance references the Bitmap instance, and in your case your code also references the Bitmap instance. Unless at some point you are calling BitmapData.clone().
There are also a couple of ways to force GC. Force Garbage Collection in AS3?
You may find it useful to attach some arbitrarily large object to something, then force the GC to see if that thing is getting cleaned up or floating around. If you are using Windows something like procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) is more helpful than task manager for doing this kind of external inspection.
This of course is a bit trial and error but for lack of something like Visual VM (https://visualvm.dev.java.net/) we are kind of screwed in the Flash world.
It's a good question, but to the best of my knowledge, the answer is no -- neither Bitmap nor BitmapData objects possess references to the loaders that load them, so you can safely use them without concern for their preventing your Loaders from being collected.
If you want to make absolutely sure, though, use the clone() method of the BitmapData class:
clone()
Returns a new BitmapData object that
is a clone of the original instance
with an exact copy of the contained
bitmap.
For example:
private function onCreationComplete():void
{
var urlRequest:URLRequest = new URLRequest("MyPhoto.jpg");
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loader_complete, false, 0, true);
loader.load(urlRequest);
}
private function loader_complete(event:Event):void
{
var img1:Image = new Image();
img1.source = Bitmap(event.target.content);
addChild(img1);
var img2:Image = new Image();
img2.source = new Bitmap(event.target.content.bitmapData.clone());
addChild(img2);
}
Here, img1's source is a Bitmap cast explicitly from the BitmapData object returned by the loader. (If you examine the references in FlexBuilder, you'll see they are identical.) But img2's source is a clone -- new bunch of bytes, new object, new reference.
Hope that helps explain things. The more likely culprits responsible for keeping objects from being garbage collected, though, are usually event handlers. That's why I set the useWeakReference flag (see above) when setting up my listeners, pretty much exclusively, unless I have good reason not to:
useWeakReference:Boolean (default =
false) — Determines whether the
reference to the listener is strong or
weak. A strong reference (the default)
prevents your listener from being
garbage-collected. A weak reference
does not.
you may set a variable in the complete listener that stores the bitmap and then destroy the object later
public function COMPLETEListener(e:Event){
myBitmap = e.target.loader.content;
}
public function destroy(){
if(myBitmap is Bitmap){
myBitmap.bitmapData.dispose();
}
}
works fine for me load some big image and see the difference in the taskmanager