Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


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: 424

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: 18208

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



#3 swiftcoder   Senior Moderators   -  Reputation: 12924

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