Open ImmersiveTheatres opened 10 months ago
/Users/aw/stellarium/src/core/StelApp.cpp:915: OpenGL error: 1282 (GL_INVALID_OPERATION)
I can reproduce this when I turn on spheric mirror distortion. Something works badly there. But I don't reproduce the slowdown.
If you speed up time, does the animation look choppy, or is it only panning around that has this problem?
Thanks for your reply. With my shows I don't do any panning around. I only speed up / slow down time. The more I speed up time, the more choppy the animation looks.
If it may help, here is the Log file of my smooth Stellarium v19.3 on MacBook Pro (2019) with 2.8 GHz Quad-Core Intel Core i7 chip, 16 GB memory, running macOS 10.15.7 (Catalina) - also operating with spherical mirror distortion.
Did you try v19.3 on the new machine?
I haven't tried v19.3 on the new MacBook. I will do so now. Do you suggest I remove v23 - or can I keep both versions on the laptop?
Do you suggest I remove v23 - or can I keep both versions on the laptop?
I have no idea about the macOS environment. To be on the safe side I'd remove the other version first.
OK great, I'll do so this afternoon and report back soon
You can keep both (or more) versions on the laptop - just change names of packages
Actually, v19.3 won't open on the new MacBook - I think because it's an Apple M3 chip (not Intel)?
Actually, v19.3 won't open on the new MacBook - I think because it's an Apple M3 chip (not Intel)?
Why not? Rosetta2 works ;)
Rosetta2 works
Won't it lead to a performance hit, especially if the problem is in some CPU-bound computation?
I don't know - when I try and open v19.3 it crashes. You can see the crash log file here.
Is it maybe crashing because v23.3 is also on the system - or because it's not an Intel chip?
Don't know about the crash, but this line makes me wonder:
OpenGL supported version: "2.1 Metal - 88"
What if you run v23.3 with --opengl-compat
command line option?
OK I'd love to try, but I have no idea how to launch Stellarium with command line options.
If you could please explain how to do it step-by-step, I should be able to do it?
I don't know - when I try and open v19.3 it crashes. You can see the crash log file here.
Is it maybe crashing because v23.3 is also on the system - or because it's not an Intel chip?
Please delete file ~/Library/Application Support/Stellarium/data/ssystem_minor.ini before run v0.19.3 because newest version of file is not compatible with v0.19.3
Rosetta2 works
Won't it lead to a performance hit, especially if the problem is in some CPU-bound computation?
No performance hit, at least I don’t see it (maybe 1-2%)
OK cool, I deleted _ssystemminor.ini, and now v19.3 runs on the new MacBook - and daily motion is beautiful and smooth 😊✨
OK cool, I deleted _ssystemminor.ini, and now v19.3 runs on the new MacBook - and daily motion is beautiful and smooth 😊✨
Please check v0.22.2 and v0.21.3 also - https://github.com/Stellarium/stellarium/tags
@alex-w how do we run Stellarium with a command line option?
@alex-w how do we run Stellarium with a command line option?
In Terminal.app: ./Stellarium.app/Contents/MacOS/stellarium --opengl-compat
Wow. OK, so this is the test result of daily motion on the new MacBook Pro M3:
Shall I run that command in the Terminal app? Do I need to do anything before / after I run it?
Wow. OK, so this is the test result of daily motion on the new MacBook Pro M3:
- v19.3 - super smooth
- v21.3 - super smooth
- v22.2 - super smooth
- v23.3 - choppy
Probably v1.0 will be smooth and v1.1 will be choppy
Shall I run that command in the Terminal app? Do I need to do anything before / after I run it?
Go to directory where Stellarium is located within Terminal.app
OK, I ran the --opengl-compat command in Terminal from the directory where Stellarium v23.3 is located.
Terminal executed a lot of commands, and then Stellarium v23.3 launched automatically.
I tried daily motion - and it is still choppy 😐
I have now installed and tried more versions on the new M3 laptop.
This is the result:
SMOOTH
CHOPPY
My problem is that I have now created a script for v23.3. The script is long and complex, but it runs perfectly in v23.3.
Unfortunately, the script does not run in v22.2 (the most recent version with smooth motion) 🫤
Where does it break? User Guide, Table 17.1 is crucial for compatibility between 0.22 and 1+ versions, but else? Maybe some functions were called slightly differently. The logfile or script GUI can help finding the unknown function. Or do you use some critical new addition?
Please run v23.3 with --opengl-compat
option and post the resulting log.txt
. The switch from v1.0 to v1.1 added support for OpenGL 3.3 Core on macOS, which is what this option turns off.
OK I ran v23.3 with --opengl-compat. Daily motion is still choppy, and the log.txt is here
Where does it break? User Guide, Table 17.1 is crucial for compatibility between 0.22 and 1+ versions, but else? Maybe some functions were called slightly differently. The logfile or script GUI can help finding the unknown function. Or do you use some critical new addition?
It doesn't really break / cause an error. In v22.2 it loads, runs, and then fails to execute these commands:
// SHOW ZODIAC CONSTELLATION ARRAY
ConstellationMgr.deselectConstellations(); ConstellationMgr.setFlagArt(true); ConstellationMgr.setFlagBoundaries(false); ConstellationMgr.setFlagLines(false); ConstellationMgr.setFlagLabels(false); ConstellationMgr.setFlagIsolateSelected(true);
// HAVE CONSTELLATIONS APPEAR IN REVERSE UNTIL LEO
for(i = zodiac.length - 1; i >= 0; i--) { core.selectConstellationByName(zodiac[i]); core.wait(1.5); }
It's an easy and related to changes in identifier for default sky culture
var zodiac = new Array("Gemini", "Cancer", "Leo", "Virgo", "Libra", "Scorpius", "Ophiuchus", "Sagittarius", "Capricornus", "Aquarius", "Pisces", "Aries", "Taurus");
// SHOW ZODIAC CONSTELLATION ARRAY
var version = core.getStelProperty("StelApp.version")[0];
if (version<23) {
core.setSkyCulture("western");
} else {
core.setSkyCulture("modern");
}
ConstellationMgr.deselectConstellations();
ConstellationMgr.setFlagArt(true);
ConstellationMgr.setFlagBoundaries(false);
ConstellationMgr.setFlagLines(false);
ConstellationMgr.setFlagLabels(false);
ConstellationMgr.setFlagIsolateSelected(true);
// HAVE CONSTELLATIONS APPEAR IN REVERSE UNTIL LEO
for(i = zodiac.length - 1; i >= 0; i--)
{
core.selectConstellationByName(zodiac[i]);
core.wait(2);
}
Awesome, thank you @alex-w - now the constellations are appearing correctly!
There are a few more glitches with the script in v22.3(v1.0) .... please stand by I will share them shortly ...
OK, the next issue is that the on-screen label / text is now very 'squashed' ie. the spacing between the letters is reduced. So it's difficult to read.
This is the code I'm using:
// DEFINE THE SHOW TEXT FUNCTION WITH COLOUR AND POSITION ON THE SCREEN
function showText(text, time) { var labelID = LabelMgr.labelHorizon(text, 160, 10, true, 30, "#ff0000"); core.wait(time); // You could also use this parameter to define how long the text will be shown return labelID; // Return the label ID for later reference }
// SHOW LOCATION, DATE AND CARDINAL POINTS
var bethlehemLabelID = showText("Bethlehem 12 August 3 BC 04:30", 1);
OK, the next issue is that the on-screen label / text is now very 'squashed' ie. the spacing between the letters is reduced. So it's difficult to read.
It's bug in series 0.22 for HiDPI systems and spheric mirror distortion mode.
You can try use:
var size = 30;
var version = core.getStelProperty("StelApp.version")[0];
if (version<23) {
size *= 2;
}
var labelID = LabelMgr.labelHorizon(text, 160, 10, true, size, "#ff0000");
But any way scripting issues are separate issues
Excellent, thank you @alex-w. The font is still squashed (I guess due to the bug), but now I can modify its size, to make it more legible.
Now my script is executing correctly on v22.3(v1.0) for macOS (universal; macOS 11.0+) ie. the last Stellarium version with smooth daily motion.
I'm running it on my new MacBook Pro M3. So I'm very happy, thank you to everyone for your help.
This is all good, but the core issue remains unsolved. Somewhere between v1.0 and v1.1 some commit leads to a performance drop.
I guess we'll need a bisection to find the culprit. This is about 8 different versions to try. @alex-w Could you make a build of the commit that git bisect start v1.1 v1.0
checks out, and then drive git bisect
with testing results, making a new build each time?
BUT - I would like to ask one final question please:
I have also installed v22.3(v1.0) for macOS (x86_64; macOS 10.15+) on my old MacBook Pro (2019) with 2.8 GHz Quad-Core Intel Core i7 chip, 16 GB memory, running macOS 10.15.7 (Catalina).
To my surprise, Stellarium v22.3(v1.0) runs fine on my old MacBook, with very smooth daily motion.
Yet when I load my Christmas Star script, at first it seems to load fine, with no errors ... but then it does not run smoothly. It seems to trip, with commands executing simultaneously and not in sequence.
So my question please: how easy (or hard?) is it to make the script work in v22.3(v1.0) for macOS (x86_64; macOS 10.15+) ?
The reason I want to do this, is because I have a LOT of fulldome content on my old MacBook, and I don't have time to transfer it across to the new MacBook (and configure it correctly), before my special Christmas planetarium shows.
It would be easier if I could run my NEW Stellarium script on my OLD MacBook Pro (so I have everything together, especially for audience Q&A time).
But if it's too difficult to adapt the script, it's OK, I will use both laptops in my shows (one for the Christmas Star, and one for the rest of the show, Q&A, etc).
Thank you @alex-w - but all five packages require macOS 11+
My old MacBook is macOS 10.15
Thank you @alex-w - but all five packages require macOS 11+
My old MacBook is macOS 10.15
Yes, I need a test of performance on your new MBP
Sorry, I don't have the time now, as I need to prepare for my Xmas shows. I will run the test after 23 December.
ANOTHER BUG?
One the MacBook Pro M3, with Stellarium v22.3(v1.0) - the planet auto-zoom feature does not appear working correctly.
After selecting the planet, the forward-slash key zooms into the planet.
But when selecting the backslash key - the initial auto-zoom does not "return to the initial FOV and direction of view" (as it says in the manual)
It moves to a different FOV (the horizon is curved and 90-deg wide, not 180-deg); with the forward position of view no longer South, but the direction of the location of the planet.
I've checked the config settings, and they're all the same as my old v19.3.
So I'm not sure if there's something I need to change, or if this is a bug?
It's correct behaviour, please check settings for this option:
OK, it looks like a bug. In the future, please report about strange behaviors or feature requests in separate issues to better resolving the problems and prepare solutions.
@ImmersiveTheatres please check release 24.3
Good timing! I have just purchased a new MacBook Pro, and it arrives later this week. I will transfer my planetarium applications to it, and the first thing I will test is Stellarium. I will begin with v24.3 (but I may have to try older versions if I encounter problems).
Below are the specs of my new MacBook Pro - what do you think, will v24.3 run well?
Has anyone tried v24.3 on the latest MacBook Pro yet?
The only question will be: Does Apple's touchpad finally work like the rest of the world? The issues around the zoom behaviour (unrelated to "Bad performance in Mac M3") have not been changed so far, but hopefully later this year.
Does Apple's touchpad finally work like the rest of the world?
It may have been working normally all this time. I still think the problem is in Qt, if you mean #2778. Anyway, I don't find any mention of the touchpad in this thread, are you sure it's the one to blame?
OK, I should have read the whole again, sorry. The GL_INVALID_OPERATIONs are probably not related to our usual suspect, the odd mac touchpads (or their unexpected behaviour. Maybe it is a Qt thing, but then other programs also should misbehave often enough for Qt to notice...). Hiding as off-topic...
I have been asked to open a new issue with this request
I am not a coder. I am an astronomy teacher. I am asking this question (and other questions below) because I don't understand deep coding - and this is a forum to help Stellarium users.
I work with inflatable planetariums, and over the past 10 years I have used Stellarium as my main astronomy application. I use the spherical mirror projection mode, and I think Stellarium is awesome.
I only use MacBook Pros in my planetariums.
Last week I installed Stellarium v23.3 (Stellarium-23.3-qt6-macOS.zip) on a brand new MacBook Pro (Nov 2023) with M3 Pro chip, 18 GB memory, running macOS 14.1.2 (Sonoma).
Previously I was using Stellarium v19.3 on a MacBook Pro (2019) with 2.8 GHz Quad-Core Intel Core i7 chip, 16 GB memory, running macOS 10.15.7 (Catalina). The Stellarium motion of the sky (diurnal motion) on this old laptop is perfect, silky-smooth and absolutely beautiful.
Unfortunately, the motion of the sky on my new laptop is currently rough, juddery and sticky.
I am using the same config file settings as on my old laptop - yet changing these settings seems to make no difference to the quality of the motion:
[video] dithering_mode = color888 fullscreen = true maximum_fps = 50000 minimum_fps = 100 screen_h = 768 screen_number = 1 screen_w = 1024 screen_x = 237 screen_y = 85 tm_display_adaptation_luminance = 50 viewport_effect = sphericMirrorDistorter
Here is my log file after I launch Stellarium (without doing anything else). I wonder if anyone can please suggest something I can change, to make the motion of the sky work more smoothly?
I'm also wondering why the following error is so strong ie. is there something I can do about this error, or not? (if possible, an answer in non-technical language would be helpful please).
/Users/aw/stellarium/src/core/StelApp.cpp:915: OpenGL error: 1282 (GL_INVALID_OPERATION)
Here is the full config.ini I am using at the moment.
Thanks very much
Mario