[PointRenderer] Assign PointRenderer to each point or to the View

[andreas]

Should we assign the PointRenderer to each point or to the view
rendering the points?

PointRenderer on Point
----------------------------------
Each point has a PointRenderer assigned.

Pros:
* Each point can be easily rendered differently
* More flexibility

Cons
* PointRenderer doesn't know the view it will be rendered for. So it
can not adapt its properties (e.g. size)
* PointRenderer might not make sense for specific view (e.g. AR Point
Renderer on RadarView)
* Unnecessary overhead since every point needs a renderer (e.g. makes
no sense for lists)

PointRenderer on View
---------------------------------
The information how a point is rendered is stored on the view. Point
doesn't know if and how it will be rendered.

Pros:
* One renderer for all points on each view
* Renderer has access to view's public properties (e.g. view size,
center, location ...)
* Default renderer for points assigned to each view
* Points could be rendered specifically based on point type
(inheritance), or a specific property using the same renderer
* More controllable & more stable

Cons:
* More complex to render points differently on one view
* Specific renderer interfaces needed for each view to allow only
supported renderers

Open for discussion!!!

[Sergi Martínez]

Some answers:

* PointRenderer might not make sense for specific view (e.g. AR Point
Renderer on RadarView)
* Unnecessary overhead since every point needs a renderer (e.g. makes
no sense for lists) 

Keep in mind that Java is using "pointers" for classes, so, assigning the same object to a lot of properties doesn't generate any overhead, as they are all pointing to the same instance. In the example of the Radar, despite we have X points, there is only one instance of the renderer, as all them are using the same instance in the same physical address.

My proposal is to use both mechanisms. Assign a renderer to the view, and this will be used by the points not having a renderer by themselves.  So, the order will be:

* has the point a renderer? if yes, use it

* if not, has the view a renderer? if yes, use it

* if not, use simplerenderer

What do you think?

--
You received this message because you are subscribed to the Google Groups "Appunta" group.
To post to this group, send email to app...@googlegroups.com.
To unsubscribe from this group, send email to appunta+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/appunta?hl=en.

--

Sergi Martínez

sergi.m...@gmail.com

http://sergiandreplace.com

[Andreas Blick]

I'm not convinced! 

I agree that in Java as in Objective-C you can use pointers to assign the renderer to a point, but logically it will still be an uneccessary overhead of information. All the information you need on the view, as there is size, orientation, direction, visibile area are defined on the view or more correct the view controller. To be able to render a point correctly you will also need this information on the point renderer. So, in my opinion it makes more sense to have the renderer where this information is needed.

One example: In case of the Radar View, I have an rectangular view, but will only render points that are inside of the radar circle. Normally this radar circle displays the area, which the camera can see in a different color, so the points might also have a different color in this area. The information I need to render the point correctly is only defined on the view.

Another reason for having the renderer attached to the view instead of the point is, that points are not necessarily visual information. They might not be rendered, but just be displayed in a list or used for calculations. Having a renderer makes no sense in this case.

And one more: If I render a point for a Radar View and later, or at the same time, in an augmented reality view, this point will be rendered differently. That means it needs more than one renderer attached and has to know which one to be used for each view. This can be achieved on much more logical way assigning the renderer to the view.

A shame it's just the two of us discussing this topic, as it would be good to get some more opinions.

2012/2/16 Sergi Martínez <sergi.m...@gmail.com>

[Sergi Martínez]

Yes to all, but that's solutione adding the "view rendererers", then you can use the approach that best fits for each view.

[Andreas Blick]

OK, so if I get you right you prefer the two way solution:

PointRenderer: Can be added to each point

ViewPointRenderer: Can be added to the view

Unless a point has a renderer assigned, the renderer attached to the view will be used. 

I can live with that ;-) ... but you still have to explain me how you asure that the assigned PointRenderer works with the view and how you render the same point differently (RadarView, ARView).

2012/2/16 Sergi Martínez <sergi.m...@gmail.com>

[Sergi Martínez]

OK, let me think about it and I'll come with a proposal :)

Btw, Jordi has access, but he's shy.

[Jordi Bernabeu]

Hi,

I agree with Sergi in having the most flexible solution, so you can use whatever approach is best suited for your current needs.

You can go like this:

1. is the point set to rendering=yes? (you can have points that need no attached renderer)

2. is there a renderer attached to the point? If yes, use it

3. is there a renderer attached to the view where the point is to be shown? If yes, use it

4. no explicit renderer yet? Then assign default simplerenderer.

Jordi

2012/2/16 Sergi Martínez <sergi.m...@gmail.com>

[Andreas Blick]

Well, I prefer stability over flexibility ;-) So let's find a flexible and stable solution, combining the two approaches ...

My proposal based on your comments:

The decision for rendering a point I would do by inheritance and interface definition, instead of a boolean. 

A simple point object can always and only be rendered by ViewPointRenders. If a specific Point object conforms to the "RenderizablePoint" interface, it can/must(?) have a renderer attached. I think this is the cleaner solution.

The decision to use the renderer attached to a point should be done by the ViewPointRenderer. The default implementation checks if the point conforms to "RenderizablePoint" and if so leaves all the rendering to the PointRenderer.

A custom ViewPointRenderer implementation can than decide, based on the view it is attached to, whether it supports a custom "PointRenderer" or not.

What do you think?

[Jordi Bernabeu]

I agree that decision should not belong to a simple boolean, of course ;)

I'll try to get to a specific example, to see if I understand the implications of the different approaches, ok?

Let's set the example of a AR screen. I have the camera image with AR points overlaid + a radar view in one corner. I want to handle 2 sets of data points: a collection of 10 points representing hotels and 5 points representing bus stations. I want to show a hotel point in AR view using a "H" icon and blue marker, and bus points using a "B" icon and red marker. In the radar view I want all 15 points to be shown as white dots.

I can then define 3 renderers: white dots, blue H pins, red B pins. Actually, I can even inherit white renderer from simplerenderer and both H and B renderers from a certain AR renderer.

I can have 3 collections of points: 10 H points, 5 B points, 15 "all" points.

Following the approach that renderer is tied to point (or point collection): I would then associate collection H to renderer H and then link the point collection to view AR, collection B to renderer B and view AR, collection "all" to renderer white and view radar.

In case the renderer is tied to the view, it would not be possible to have both H and B renderers attached to the AR view? I think this implies that H and B renderers are not really different, but are both a single renderer AR that displays a given icon and a given colour (and the particular icon and colour to use for each point would then be defined within the point?).

Would it be: view AR is associated to renderer AR, and also contains point collections H and B. Each point collection in its own contains some parameters needed be renderer AR? This seems too complicated and messy to me, but maybe I'm not getting the point here :)

Comments?

Jordi

[Andreas Blick]

Great example! I also like the idea of collections, but:

1. Using collections of "types" of points makes implement logic for managing those collections.
2. Your example duplicates points to display them differently in AR- and RadarView. I don't think this is good approach. 
3. If I want to render a point with different images or maybe 3D models in the future, this information has to be stored on the point and not on the renderer. If not I still need a renderer instance for each point and can not work with pointer

Until here my critics. Now my new proposal:

• We use PointRenderers attached or assigned to each point by reference. 
  That way we can render each point differently.
• A PointRenderer has to conform to one of various interfaces, which are related to the view they are supposed to be rendered for.
  The view needs to be passed into the renderer to give it access to the views properties.
  The Point itself needs to conform to a specified interface and holds all the additional data necessary for being rendered by its attached renderer
  That way we assure it works on the supported views only.
• Each Point-View combination has a default renderer which is applied when no concrete renderer is specified
  That way we assure each point can be rendered
• A Point can have various renderers assigned, one for each supported view, to be able to render correctly on each view. If it doesn't have a renderer for the view it is supposed to be rendered on, but conforms to the corresponding Point interface, the default is applied. If it doesn't conform to the interface it is simply ignored and not rendered.
  I'm not really convinced about this point, but it's a possible solution for not having to duplicate points.

Possible interface definitions:

• ARPoint
• ARImagePoint
• AR3DModelPoint
• RadarPoint

Possible renderer interface definitions:

• ARPointRenderer
  
• Only renders points conforming to the ARPoint interface
• RadarPointRenderer
• Only renders points conforming to the RadarPoint interface