[Marble-devel] Review Request: Inter-layer interactions
Paul Nader
paul.nader at gmail.com
Wed Feb 22 21:37:49 UTC 2012
> On Feb. 6, 2012, 3:41 p.m., Bernhard Beschow wrote:
> > > I am more trying to get feedback/ideas here rather than pushing for the patch to be incorporated...
> >
> > Given your usecase, it seems to me that you rather want to control the avaliability of certain placemarks for rendering, such that e.g. Madrid isn't considered by the code that selects the visible placemarks. As such, it should suffice if you controlled the model rather than "fixing" the rendering part.
> >
> > Moreover, if you want to show labels in different layers while at the same time avoiding collisions of labels, perhaps one layouting instance should be made accessible to both the PlacemarkLayout and your custom layer, such that it can determine the positions of all visible labels accross the two layers. PlacemarkLayout and your custom layer could then draw their respective labels using the positions determined by the layouting instance.
> >
> > Does that seem to fit your needs?
>
> Paul Nader wrote:
> > Moreover, if you want to show labels in different layers while at the same time avoiding collisions of labels, perhaps one layouting instance should be made accessible to both the
> > PlacemarkLayout and your custom layer, such that it can determine the positions of all visible labels accross the two layers. PlacemarkLayout and your custom layer could then draw their
> > respective labels using the positions determined by the layouting instance.
>
> Thanks for your input.
>
> Yes, this seems a cleaner approach by having a LayoutManager taking care of laying out several layers. My approach was to take the output result of the PlacemarkLayout layout (ie the vector of VisiblePlacemarks) and make that available to the layout manager in my custom layer. This allows my layer to hide placemarks from layers below it which collide with its own placemarks. If a single layout manager was in charge of managing both layers it could try to do the same, or even allow for different behaviours (eg hiding or not hiding placemarks) using some sort of policy control.
>
> Would the LayoutManager approach would still require two passes, one for laying out and one for the final painting?
>
> Bernhard Beschow wrote:
> Well yes, layouting has to happen before any painting is done. However, I think that can be solved e.g. by implementing a pseudo layer. This layer would be the first layer that gets "rendered", but instead of rendering, it would just calculate a layout (withough actually rendering anything). The result of the layouting could then be used by the other layers.
> Even though this approach is a hack as well, it doesn't break our current design. Moreover, I plan to separate visibility management (e.g. culling) and rendering anyway. So once this is done, the code inside the pseudo layer could be ported with very minimal changes.
>
> The real challenge I currently see is how the layers are supposed to tell the LayoutManager what they wish to be visible and what not. I currently don't have an idea of how that could acutally work in an extensible and flexible way. Perhaps the simplest implementation which just fits your needs is best here. We can change the code any time if we have an better idea. What would be great, though, would be unit tests, such that things don't break when we change the code.
>
> What do you think?
Ideally marble would support multiple placemark layers. There are two issues to "solve" as far as I can see. One is the reuse of PlacemarkLayout and the other is how the placemark layers interact.
PlacemarkLayout should be exported (+ dependencies such as the placemarkpainter) to enable reuse. I have done that in my repository which is how I drew the nodes in the image attached.
If we assume multiple placemark layers, and the pseudo layer you mentioned above is made responsible for laying all of the layers without rendering them it would need access to each layer layout items. It would need to hold information on how to do this (ie should it hide objects that are partially obscured or not? Move them about?). Not sure there are many more use cases other than that.
As you know the solution I provided made each layer responsible for hiding placemarks from layers below.
Feel free from bouncing any ideas you may have with me.
- Paul
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103867/#review10373
-----------------------------------------------------------
On Feb. 4, 2012, 8:25 p.m., Paul Nader wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103867/
> -----------------------------------------------------------
>
> (Updated Feb. 4, 2012, 8:25 p.m.)
>
>
> Review request for Marble, Dennis Nienhüser and Thibaut Gridel.
>
>
> Description
> -------
>
> This patch enables interaction between marble layers. Currently each LayerInterface rendered through LayerManager is independent of each other. It is currently not possible to control the rendering of objects in a layer based on the visible placemarks of layers below it. (eg., a user of the library creates a new layer similar to PlacemarkLayer but wishes to ensure that the labels for its visible placemarks do not overlap with labels of placemarks drawn in a layer below it. Nor is it possible to affect the rendering of a layer below the current layer (eg., disallow the rendering of any placemarks below the placemark in the current layer).
>
> This patch allows a layer to see the visible placemarks for all layers already rendered and to modify the lower layers visible items:
>
> - Added a new parameter to LayoutInterface::render which contains a vector of all previous LayerInterfaces already rendered.
> - Added a VisiblePlacemarks vector member to LayerInterface (with getter/setter)
> - Added a paint method to LayerInterface. Layers wishing to cooperate should compose/create their visible placemarks in the render method (but not paint them) using the new vector container added to LayerInterface. The visible placemarks are then drawn in the paint method.
> - Modified LayerManager to pass a vector of previous layers when calling render and to loop through the layers calling the paint method after that.
> t.t
>
> This patch is crude (I admit) but its a start nonetheless. I am more trying to get feedback/ideas here rather than pushing for the patch to be incorporated...
>
> The screenshow shows an application of its use. Here there is a user placemark layer used to draw the nodes of a network. This ensures the nodes are always above the marble city placemarks. A second use layer draws the links below the nodes. Using the patch I could hide any city placemarks directly below the nodes (eg, Madrid and Malaga are not visible because they have been hidden by the user placemark layer). Also, some of the node labels have been moved after they detected a collision with the labels of placemarks close to them.
>
>
> Diffs
> -----
>
> src/lib/AbstractDataPlugin.h aca7aa0
> src/lib/AbstractDataPlugin.cpp 2881e19
> src/lib/AbstractFloatItem.h ea6050e
> src/lib/AbstractFloatItem.cpp 9de45b5
> src/lib/CMakeLists.txt af2c4db
> src/lib/LayerInterface.h 1241ccc
> src/lib/LayerManager.cpp 62bb4aa
> src/lib/MarbleMap.cpp 90238da
> src/lib/MarbleWidget.cpp f811854
> src/lib/VisiblePlacemark.h 0518815
> src/lib/kdescendantsproxymodel.h 6908bff
> src/lib/layers/AtmosphereLayer.h b68dd60
> src/lib/layers/AtmosphereLayer.cpp c05d6e3
> src/lib/layers/FogLayer.h e86f79d
> src/lib/layers/FogLayer.cpp 24a1325
> src/lib/layers/FpsLayer.h eb3743f
> src/lib/layers/FpsLayer.cpp 9c07485
> src/lib/layers/GeometryLayer.h 70e97ba
> src/lib/layers/GeometryLayer.cpp 1c24153
> src/lib/layers/MarbleSplashLayer.h 2ef2e7b
> src/lib/layers/MarbleSplashLayer.cpp bed786a
> src/lib/layers/PlacemarkLayout.h cfad7f7
> src/lib/layers/PlacemarkLayout.cpp 8c9aca7
> src/lib/layers/TextureLayer.h efc9ef2
> src/lib/layers/TextureLayer.cpp a7943bf
> src/lib/layers/VectorMapBaseLayer.h 7db584e
> src/lib/layers/VectorMapBaseLayer.cpp 1bf1fbd
> src/lib/layers/VectorMapLayer.h 91a3f35
> src/lib/layers/VectorMapLayer.cpp f05c88a
> src/lib/routing/RoutingLayer.h ba8b295
> src/lib/routing/RoutingLayer.cpp 8a3a44a
> src/plugins/render/aprs/AprsPlugin.h d073872
> src/plugins/render/aprs/AprsPlugin.cpp 514aa1d
> src/plugins/render/crosshairs/CrosshairsPlugin.h fc28128
> src/plugins/render/crosshairs/CrosshairsPlugin.cpp 975d5de
> src/plugins/render/graticule/GraticulePlugin.h 339ca44
> src/plugins/render/graticule/GraticulePlugin.cpp 96c58f7
> src/plugins/render/measure/MeasureToolPlugin.h 366d36c
> src/plugins/render/measure/MeasureToolPlugin.cpp 54e4605
> src/plugins/render/positionmarker/PositionMarker.h 95be7ec
> src/plugins/render/positionmarker/PositionMarker.cpp 44b5ded
> src/plugins/render/satellites/SatellitesPlugin.h 808e9df
> src/plugins/render/satellites/SatellitesPlugin.cpp 2ca0775
> src/plugins/render/stars/StarsPlugin.h 1c306e1
> src/plugins/render/stars/StarsPlugin.cpp e09bf99
> src/plugins/render/sun/SunPlugin.h 514f94d
> src/plugins/render/sun/SunPlugin.cpp 2258377
>
> Diff: http://git.reviewboard.kde.org/r/103867/diff/
>
>
> Testing
> -------
>
>
> Screenshots
> -----------
>
>
> http://git.reviewboard.kde.org/r/103867/s/425/
>
>
> Thanks,
>
> Paul Nader
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20120222/e02ac5d0/attachment.html>
More information about the Marble-devel
mailing list