Processing 1.0 - Processing Discourse - Layer ordering with registerDraw: proof of concept

blindfish

Layer ordering with registerDraw: proof of concept
Jan 5^th, 2010, 3:13am

I have a rather unhealthy interest in using registerDraw() in my classes to avoid the need to jumble calls to class display methods in the main Processing draw loop. One slight limitation I've come across with this approach is the inability to change the drawing order (in effect the layer order) of objects once they're registered.

I know there's a fully featured layers Library that's recently been released; but in many cases I suspect this may be overkill... So I've just built a proof of concept of one crude approach (description is on the page):

http://www.blindfish.co.uk/code/processing/layers02/

This solution actually seems rather obvious, and has been at the back of my mind for a while. Unless there are obvious issues with the approach (e.g. I don't know if it would cause performance issues when dealing with large numbers of objects...) I may have a go at developing it further...

Where is the what if the what is in why?

Cedric God Member Offline Posts: 1838	Re: Layer ordering with registerDraw: proof of concept Reply #1 - Jan 5^th, 2010, 3:18am interesting, registerDraw was new to me, so for everybody who doesnt know what its there for : http://processing.org/hacks/hacks:registerevents
	twitter.com/CedricKiefer

knutEinar Junior Member Offline Posts: 55 Norway	Re: Layer ordering with registerDraw: proof of concept Reply #2 - Jan 6^th, 2010, 3:07am I'm not sure if I get the usefulness of this. It takes away a lot of control over the objects, IMO, but maybe it can be useful in terms of dealing with 'particles' as opposed to 'objects' ... The whole idea of not having a reference to each object is somewhat scary to me

blindfish

Re: Layer ordering with registerDraw: proof of concept
Reply #3 - Jan 6^th, 2010, 4:14am

There are probably some situations in which registerDraw() doesn't make sense, but I'm not sure I understand your concern: you can still reference an object in the main draw loop if need be, but generic class-specific display functionality can be handled within the class itself, which can actually then make it more straightforward to handle complexities in the main draw loop.

For an example of this in practice see:

http://www.openprocessing.org/visuals/?visualID=6602

The main draw loop is used to handle collision detection etc.; but the general display and mouse-handling stuff is safely tucked away in the class itself.

I've made some more progress with implementing a class to re-order layers, though there are some definite gotchas...

Where is the what if the what is in why?

blindfish God Member Offline Posts: 793	Re: Layer ordering with registerDraw: proof of concept Reply #4 - Jan 6^th, 2010, 11:38am Just uploaded my latest experiment with this (code now moved into a more fully featured class): http://www.blindfish.co.uk/code/processing/layers03/ Feedback appreciated - i.e. is this an acceptable approach to the problem? Are there better solutions? Thanks
	Where is the what if the what is in why?

knutEinar

Re: Layer ordering with registerDraw: proof of concept
Reply #5 - Jan 7^th, 2010, 12:52pm

blindfish wrote on Jan 6^th, 2010, 4:14am:

There are probably some situations in which registerDraw() doesn't make sense, but I'm not sure I understand your concern: you can still reference an object in the main draw loop if need be, but generic class-specific display functionality can be handled within the class itself, which can actually then make it more straightforward to handle complexities in the main draw loop.

In the other example, linked to by Cedric, there was made a bunch of objects, 1000 to be precise, but no array ref to control them. I didn't even think they could exist without being referenced to by an array, or some other reference variable, but it seems I was wrong about that :) In your example, you have an reference array, and to me that looks better :) i.e. b = new Ball[numBalls];

blindfish

Re: Layer ordering with registerDraw: proof of concept
Reply #6 - Jan 7^th, 2010, 3:29pm

I see what you mean; though that's possibly what they mean on the Hacks page by:

Quote:

Also keep in mind that you cannot retrieve the list of objects listening for a specific event so if you need to send some other message to all of your listeners, you'll still need to keep an array around for reference.

Though if you use my bfLayers class and add the objects to layers you'll have access to an array of all the objects anyway Wink

And for anyone who's interested I've uploaded another demo:

http://www.blindfish.co.uk/code/processing/layers04/

Where is the what if the what is in why?

knutEinar Junior Member Offline Posts: 55 Norway	Re: Layer ordering with registerDraw: proof of concept Reply #7 - Jan 8^th, 2010, 2:15am I just thought every object in Java had to be referenced, or else it would go to garbage collection. I'm trying to understand this (i.e. Java), but every time I think I do, it turns out to not be how I think it works after all

d.rifkin

Re: Layer ordering with registerDraw: proof of concept
Reply #8 - Jan 8^th, 2010, 2:43am

The object will still be referenced internally in the PApplet. When you call registerDraw(), the object you passed to registerDraw() is added to the drawMethods variable (which is an instance of the RegisteredMethods class). Here's the source to PApplet in case you want to take a look:

http://dev.processing.org/source/index.cgi/tags/processing-1.0.9/core/src/processing/core/PApplet.java?rev=5766&view=markup

blindfish God Member Offline Posts: 793	Re: Layer ordering with registerDraw: proof of concept Reply #9 - Jan 9^th, 2010, 6:50am Just uploaded a more comprehensive version to openProcessing: http://www.openprocessing.org/visuals/?visualID=6890 ...and noticed a small bug [actually I think I imagined it]
	« Last Edit: Jan 10^th, 2010, 12:36am by blindfish » Where is the what if the what is in why?