1. 19 Jul, 2011 1 commit
  2. 18 Jul, 2011 1 commit
  3. 13 Jun, 2011 3 commits
  4. 01 May, 2011 1 commit
  5. 17 Apr, 2011 1 commit
    • Thibaut Gridel's avatar
      PlacemarkLayout: tile level caching of Placemarks · 14b0bb0c
      Thibaut Gridel authored
      More popular placemarks get to high-level "tile level", less popular go to low-level ones.
      For a given BBox, calculating the "Tile pyramid" and getting placemarks from those TileIds provides a small subset of placemarks that should get rendered.
      
      Some figures: we have currently c.a. 22000 placemarks, and most BBox provides an 10ish TileIds Pyramid, leading so c.a. 400 placemarks.
      The scalability of filtering placemarks sounds quite obvious.
      
      Tweaking level, placemark popIdx, and radius to level is TODO:
      - radius to level table (used to determine at which radius which level should be used),
      - popIdx to level (used to seed placemarks to level according to their PopIdx)
      - filtering the first 300 placemarks to display (should stay untouched)
      
      RB: 6604
      RevBy: Torsten Rahn
      14b0bb0c
  6. 23 Mar, 2011 1 commit
    • Bernhard Beschow's avatar
      determine whether placemarks should be drawn within... · 7a47accd
      Bernhard Beschow authored
      determine whether placemarks should be drawn within PlacenarkLayout::paintPlaceFolder() rather than in
      MarbleMap::paintGround()
      
      * considers other planets than just the earth
      * have MarbleMap not deal with specifics of placemarks
      
      svn path=/trunk/KDE/kdeedu/marble/; revision=1225815
      7a47accd
  7. 08 Mar, 2011 1 commit
  8. 15 Jan, 2011 2 commits
  9. 26 Dec, 2010 1 commit
  10. 12 Dec, 2010 5 commits
  11. 30 Nov, 2010 1 commit
    • Bernhard Beschow's avatar
      move drawing methods from MarbleModel to MarbleMap · 98b53552
      Bernhard Beschow authored
      Motivation
      ==========
      
      The whole painting should be implemented in the view rather than in the model because it decouples data and its representation. This allows for having different graphics
      backends (hello OpenGL!) while having a common interface to the data.
      
      Implementation
      ==============
      
      MarbleMap is now the owner of all painting objects, e.g. the MeasureTool, a new TextureLayer class, the LayerManager, and others. To see all painting objects owned by
      MarbleMap, see the modified MarbleMap_p.h.
      
      Since the LayerManager object is now owned by MarbleMap, the layer-relevant methods, slots, and signals (such as addLayer(), removeLayer(), renderPluginsInitialized()) are
      now forwarded by MarbleMap and Marblewidget rather than by MarbleModel.
      
      The DownloadRegionDialog has been modified to take a MarbleWidget instead of a MarbleModel.
      
      RB: 5902
      CCMAIL: kde-bindings@kde.org
      
      svn path=/trunk/KDE/kdeedu/marble/; revision=1202361
      98b53552
  12. 14 Nov, 2010 1 commit
  13. 07 Nov, 2010 1 commit
  14. 01 Nov, 2010 1 commit
  15. 29 Aug, 2010 2 commits
  16. 17 Jul, 2010 1 commit
  17. 16 Jul, 2010 1 commit
  18. 09 Jul, 2010 1 commit
  19. 06 Jun, 2010 1 commit
  20. 15 Nov, 2009 2 commits
  21. 01 Oct, 2009 1 commit
  22. 13 Jun, 2009 2 commits
  23. 08 May, 2009 1 commit
  24. 25 Apr, 2009 1 commit
    • Torsten Rahn's avatar
      · 8c2ff2f8
      Torsten Rahn authored
      - Moving the projection calculation of screenCoordinates from int to qreal. This makes our new shiny graticule look better and even seems to result in a tiny little bit better performance -- at least on desktop computers ...
      
      
      svn path=/trunk/KDE/kdeedu/marble/; revision=958993
      8c2ff2f8
  25. 03 Apr, 2009 2 commits
  26. 02 Apr, 2009 2 commits
  27. 01 Apr, 2009 2 commits