Split GeoPolygonGraphicsItem class into subtypes Building & Normal
ClosedPublic

Authored by kossebau on Sep 21 2016, 6:20 PM.

Details

Summary

GeoPolygonGraphicsItem has special code paths for polygons of buildings
which complicate the logic (and also bring a small price at
runtime, due to repeated checks or unneeded building properties).
Distinct subclasses of GeoPolygonGraphicsItem for each type make the methods
more simple and focussed.
With more work on Vector OSM I expect even more special code for
GeoPolygonGraphicsItem, so separate subclasses should help even more in the
future.

Input wanted especially on:

  • naming pattern of new classes
  • who should know about types, GeoPolygonGraphicsItem or GeometryLayer? GeometryLayer::whichBuildingAt(...) already puts concept of buildings into GeometryLayer (though GeoPolygonGraphicsItem's isBuilding() checks for even more visual categories, mismatch correct?)

Diff Detail

Repository
R34 Marble
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
kossebau updated this revision to Diff 6858.Sep 21 2016, 6:20 PM
kossebau retitled this revision from to Split GeoPolygonGraphicsItem class into subtypes Bathymetry, Building, Normal.
kossebau updated this object.
kossebau added reviewers: Marble, shentey, nienhueser, rahn.
kossebau updated this revision to Diff 6964.Sep 27 2016, 8:54 PM

Updated to latest master, dropped BathymetryGeoPolygonGraphicsItem class

kossebau retitled this revision from Split GeoPolygonGraphicsItem class into subtypes Bathymetry, Building, Normal to Split GeoPolygonGraphicsItem class into subtypes Building & Normal.Sep 27 2016, 8:56 PM
kossebau updated this object.
nienhueser accepted this revision.Oct 2 2016, 4:48 PM
nienhueser edited edge metadata.

Looks fine to me. Having GeoPolygonGraphicsItem behave like a factory looks good to me, no real preference where to put/hide the knowledge (item vs geo layer).

This revision is now accepted and ready to land.Oct 2 2016, 4:49 PM
This revision was automatically updated to reflect the committed changes.
rahn edited edge metadata.Oct 2 2016, 7:50 PM

Right now we seem to instantiate three relatively expensive texture-related objects

QString m_cachedTexturePath;
QColor m_cachedTextureColor;
QImage m_cachedTexture;

for all kind of PolygonGraphicsItems. However these textures get only rarely used (we have e.g. no textures for buildings, most areas, bathymetries, etc.). So I would suggest that we encapsulate all three texture objects into a wrapping TextureCache class which only gets referenced by a pointer. The actual TextureCache object would only get instantiated lazily when needed. This would probably save memory and instantiation time. A further optimization would take this approach further and would save much more memory (especially with regard to the image): we would reference each TextureCache object via an id that maps to the cached TexturePath (possibly also taking the cachedTextureColor into account). The TextureCache would get reference counted/cached in a dedicated cache container. As a result there would be only a single one TextureCache object instantiated for many AbstractGeoPolygonGraphicsItem-derived objects that use the same cachedTexturePath/cachedTexture-QImage.
This would again save memory and instantiation time.

src/lib/marble/geodata/graphicsitem/AbstractGeoPolygonGraphicsItem.h
49

Right now we seem to instantiate three relatively expensive texture-related objects

QString m_cachedTexturePath;
QColor m_cachedTextureColor;
QImage m_cachedTexture;

for all kind of PolygonGraphicsItems. However these textures get only rarely used (we have e.g. no textures for buildings, most areas, bathymetries, etc.). So I would suggest that we encapsulate all three texture objects into a wrapping TextureCache class which only gets referenced by a pointer. The actual TextureCache object would only get instantiated lazily when needed. This would probably save memory and instantiation time. A further optimization would take this approach further and would save much more memory (especially with regard to the image): we would reference each TextureCache object via an id that maps to the cached TexturePath (possibly also taking the cachedTextureColor into account). The TextureCache would get reference counted/cached in a dedicated cache container. As a result there would be only a single one TextureCache object instantiated for many AbstractGeoPolygonGraphicsItem-derived objects that use the same cachedTexturePath/cachedTexture-QImage.
This would again save memory and instantiation time.