Jump to content

  • Log In with Google      Sign In   
  • Create Account

Flood of "Change" Events


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Quat   Members   -  Reputation: 404

Like
0Likes
Like

Posted 19 February 2013 - 03:51 PM

I am building an editor of sorts, which means my mesh geometry can change.  Certain parts of my application will want to be notified when a mesh's geometry changes.  So I added a "GeometryChanged" event to my mesh class.  The problem is that several of my Mesh API functions can raise the GeometryChanged event, and often these calls will be made sequentially.  Here is a simple example:

 

mesh.AddVertices(...);

mesh.AddIndices(...);

mesh.Indices[3] = 2;

 

Each of these changes the geometry of the mesh, and would trigger 3 "GeometryChanged" events.  If the event handlers were heavy duty this would be pretty wasteful.  One solution I am considering is to wrap changes between a BeginGeometryChange()/EndGeometryChange pair, and only Begin/EndGeometryChange would raise events. 

 

This would work and is relatively easy to integrate, but I am wondering if there is a more elegant solution.  I find this somewhat inelegant because of the extra API calls to Begin/EndGeometryChange that the client must manually remember to call.  I can of course add debug asserts to make sure they are properly called, but still.

 

 


-----Quat

Sponsor:

#2 L. Spiro   Crossbones+   -  Reputation: 13595

Like
0Likes
Like

Posted 19 February 2013 - 04:26 PM

There is nothing wrong or inelegant with your idea to begin/end a series of events.  This is called “batching” and is the normal way to go about this.  It is also heavily used in undo/redo systems, especially related to typing events.

 

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#3 swiftcoder   Senior Moderators   -  Reputation: 9994

Like
0Likes
Like

Posted 19 February 2013 - 04:36 PM

Another approach is to wrap the begin/end calls in a scoped handle class, which calls begin when it is created, and end when it is destructed (i.e. falls out of scope)
 
class Mesh
{
	 friend class MeshModifier;
private:
	 void begin_modifications();
	 void end_modifications();

	 void add_vertices_impl();
	 void add_indices_impl();
};

class MeshModifier
{
	 Mesh &mMesh;
public:
	 MeshModifier(Mesh &mesh) : mMesh(mesh) {mMesh.begin_modifications();}
	 ~MeshModifier() {mMesh.end_modifications();}

	 void add_vertices();
	 void add_indices();
};

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#4 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 19 February 2013 - 05:01 PM

Do you need events at all? Can you flag the mesh as changed, and defer processing the change until a fixed point in the update?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS