<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/103867/">http://git.reviewboard.kde.org/r/103867/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On February 6th, 2012, 3:41 p.m., <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 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?</pre>
</blockquote>
<p>On February 7th, 2012, 2:07 p.m., <b>Paul Nader</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 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?</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?</pre>
<br />
<p>- Bernhard</p>
<br />
<p>On February 4th, 2012, 8:25 p.m., Paul Nader wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Marble, Dennis Nienhüser and Thibaut Gridel.</div>
<div>By Paul Nader.</div>
<p style="color: grey;"><i>Updated Feb. 4, 2012, 8:25 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/lib/AbstractDataPlugin.h <span style="color: grey">(aca7aa0)</span></li>
<li>src/lib/AbstractDataPlugin.cpp <span style="color: grey">(2881e19)</span></li>
<li>src/lib/AbstractFloatItem.h <span style="color: grey">(ea6050e)</span></li>
<li>src/lib/AbstractFloatItem.cpp <span style="color: grey">(9de45b5)</span></li>
<li>src/lib/CMakeLists.txt <span style="color: grey">(af2c4db)</span></li>
<li>src/lib/LayerInterface.h <span style="color: grey">(1241ccc)</span></li>
<li>src/lib/LayerManager.cpp <span style="color: grey">(62bb4aa)</span></li>
<li>src/lib/MarbleMap.cpp <span style="color: grey">(90238da)</span></li>
<li>src/lib/MarbleWidget.cpp <span style="color: grey">(f811854)</span></li>
<li>src/lib/VisiblePlacemark.h <span style="color: grey">(0518815)</span></li>
<li>src/lib/kdescendantsproxymodel.h <span style="color: grey">(6908bff)</span></li>
<li>src/lib/layers/AtmosphereLayer.h <span style="color: grey">(b68dd60)</span></li>
<li>src/lib/layers/AtmosphereLayer.cpp <span style="color: grey">(c05d6e3)</span></li>
<li>src/lib/layers/FogLayer.h <span style="color: grey">(e86f79d)</span></li>
<li>src/lib/layers/FogLayer.cpp <span style="color: grey">(24a1325)</span></li>
<li>src/lib/layers/FpsLayer.h <span style="color: grey">(eb3743f)</span></li>
<li>src/lib/layers/FpsLayer.cpp <span style="color: grey">(9c07485)</span></li>
<li>src/lib/layers/GeometryLayer.h <span style="color: grey">(70e97ba)</span></li>
<li>src/lib/layers/GeometryLayer.cpp <span style="color: grey">(1c24153)</span></li>
<li>src/lib/layers/MarbleSplashLayer.h <span style="color: grey">(2ef2e7b)</span></li>
<li>src/lib/layers/MarbleSplashLayer.cpp <span style="color: grey">(bed786a)</span></li>
<li>src/lib/layers/PlacemarkLayout.h <span style="color: grey">(cfad7f7)</span></li>
<li>src/lib/layers/PlacemarkLayout.cpp <span style="color: grey">(8c9aca7)</span></li>
<li>src/lib/layers/TextureLayer.h <span style="color: grey">(efc9ef2)</span></li>
<li>src/lib/layers/TextureLayer.cpp <span style="color: grey">(a7943bf)</span></li>
<li>src/lib/layers/VectorMapBaseLayer.h <span style="color: grey">(7db584e)</span></li>
<li>src/lib/layers/VectorMapBaseLayer.cpp <span style="color: grey">(1bf1fbd)</span></li>
<li>src/lib/layers/VectorMapLayer.h <span style="color: grey">(91a3f35)</span></li>
<li>src/lib/layers/VectorMapLayer.cpp <span style="color: grey">(f05c88a)</span></li>
<li>src/lib/routing/RoutingLayer.h <span style="color: grey">(ba8b295)</span></li>
<li>src/lib/routing/RoutingLayer.cpp <span style="color: grey">(8a3a44a)</span></li>
<li>src/plugins/render/aprs/AprsPlugin.h <span style="color: grey">(d073872)</span></li>
<li>src/plugins/render/aprs/AprsPlugin.cpp <span style="color: grey">(514aa1d)</span></li>
<li>src/plugins/render/crosshairs/CrosshairsPlugin.h <span style="color: grey">(fc28128)</span></li>
<li>src/plugins/render/crosshairs/CrosshairsPlugin.cpp <span style="color: grey">(975d5de)</span></li>
<li>src/plugins/render/graticule/GraticulePlugin.h <span style="color: grey">(339ca44)</span></li>
<li>src/plugins/render/graticule/GraticulePlugin.cpp <span style="color: grey">(96c58f7)</span></li>
<li>src/plugins/render/measure/MeasureToolPlugin.h <span style="color: grey">(366d36c)</span></li>
<li>src/plugins/render/measure/MeasureToolPlugin.cpp <span style="color: grey">(54e4605)</span></li>
<li>src/plugins/render/positionmarker/PositionMarker.h <span style="color: grey">(95be7ec)</span></li>
<li>src/plugins/render/positionmarker/PositionMarker.cpp <span style="color: grey">(44b5ded)</span></li>
<li>src/plugins/render/satellites/SatellitesPlugin.h <span style="color: grey">(808e9df)</span></li>
<li>src/plugins/render/satellites/SatellitesPlugin.cpp <span style="color: grey">(2ca0775)</span></li>
<li>src/plugins/render/stars/StarsPlugin.h <span style="color: grey">(1c306e1)</span></li>
<li>src/plugins/render/stars/StarsPlugin.cpp <span style="color: grey">(e09bf99)</span></li>
<li>src/plugins/render/sun/SunPlugin.h <span style="color: grey">(514f94d)</span></li>
<li>src/plugins/render/sun/SunPlugin.cpp <span style="color: grey">(2258377)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/103867/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots </h1>
<div>
<a href="http://git.reviewboard.kde.org/r/103867/s/425/"><img src="http://git.reviewboard.kde.org/media/uploaded/images/2012/02/04/inter-layer_400x100.png" style="border: 1px black solid;" alt="" /></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>