Bug 286982 - Rendering in marble is too slow using default configuration
Summary: Rendering in marble is too slow using default configuration
Status: RESOLVED WORKSFORME
Alias: None
Product: marble
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: some future version
Assignee: marble-bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-19 11:08 UTC by Robert Riemann
Modified: 2023-01-31 05:05 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Riemann 2011-11-19 11:08:02 UTC
Version:           unspecified (using KDE 4.7.2) 
OS:                Linux

I'm using Plasma Active 1.0 on my Exo tablet. Showing marble with openstreetmap to my friends, I always get comments on bad berformance while dragging/moving the map.

After "years" of using marble I found at, that this can be resolved (or at least highly improved) by just choosing other settings. I switched to Mercator projection and disabled this annoying grid.

Marble is so much more usefull know. Please make "without grid" and "Mercator" the default setting - or at least, show a hint in the settings menu about performance regressions when using the globe projection.

Best,
Robert 

Reproducible: Didn't try

Steps to Reproduce:
just open marble with default configuration

Actual Results:  
- rendering is very slow
- map doesn't seems to be very responsive while dragging

Expected Results:  
better performance - at least as good as on smart phones
Comment 1 Dennis Nienhüser 2011-11-22 23:25:46 UTC
Is that the Desktop version that is shipped with Plasma Active? No doubt it doesn't run well.

We're working on QML/Qt-components based mobile versions of Marble. The first one is going to be shipped with KDE 4.8 in January for Meego (Nokia N9/N950). That will be a far better candidate to use with Plasma Active. Fixing the Desktop version for a tablet is the wrong option in my opinion.
Comment 2 Torsten Rahn 2011-11-23 09:41:50 UTC
Hi,

I've seen Marble running on Exo PCs and WeTab as well. The problem is not so much with Marble and its default configuration:

* Running Marble on openSUSE on an Exo PC delivered quite decent performance (no multitouch however)
* Running Marble on plain vanilla WeTab OS (which is based on MeeGo 1.1) on a WeTab (which is basically an Exo PC) delivered quite decent performance
* Running Marble on an ExoPC with a MeeGo 1.2 based OS gives bad performance.
* Running Marble on older versions of MeeGo (1.0 or 1.1) gave good performance.

I'm not sure why Marble on MeeGo 1.2 on an Exo PC runs so slow. 
I know that it will also affect the Mercator projection (it's just not noticable because the Mercator projection is "lighter" on the hardware.
It could either be an issue with mcompositor (which is tailored for OpenGL usage) or an issue with the X drivers or an issue with the assumption that on MeeGo 1.2 software is supposed to use the OpenGL pipeline.
Comment 3 Bernhard Beschow 2011-11-23 10:00:13 UTC
@Robert: Could you run "marble --fps" from the command line? This will show the estimated frames per second in the top left corner. It would be great if you reported the numbers here for Spherical and Mercator projection... Just to know that we are on the same track when talking about performance. Thanks in advance!
Comment 4 Torsten Rahn 2011-11-23 10:06:35 UTC
BTW: Using Qt's raster graphics system already increases speed a bit (vs. native X11 mode). But that is enabled by default in Marble 1.3 (KDE 4.8) already.
Comment 5 Andrew Crouthamel 2018-11-10 03:15:02 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Andrew Crouthamel 2018-11-20 04:04:58 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Justin Zobel 2023-01-01 04:19:50 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 8 Bug Janitor Service 2023-01-16 05:13:02 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Bug Janitor Service 2023-01-31 05:05:18 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!