7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
@mabula-admin This is displayed. The issue is still there. If I remember correctly, this problem occurs since I connected a second screen. I also did a boot with just the laptop screen, but the problem persists. But maybe the problem still lies somewhere here.
Can you explain what exactly the problem is, because from your screenshot, APP loaded in just over 3 seconds. Also what GPU are you using? As it states in your console output
"GL Shading Language version: 4.60"
But mine reports
"GL Shading Language version: 4.60 NVIDIA"
Also your maximum texture size is 16384 whereas mine is 32768
the problem is, that APP doesn't start at all. All I see is a blank preview window in the task bar. Nothing happens when I click on it. It remains white in the task bar. My notebook has an AMD Radeon Graphics GPU, no NVIDIA.
Thank you very much for the feedback. Can you try the following for me to check if that changes the behaviour of APP startup on your system:
Start APP, once APP is started, click on the CFG button
Disable console output in separate window
and also disable image viewer and frame list in separate windows
click on save
restart APP.
So this makes it a single window application basically. Maybe that changes things. If it does, please let us know.
Also, and if it does, what happens if you again enable console output in a separate window and restart APP? Is it now normal or not?
Using a 2nd or even more monitors has no influence on my test systems, but if that startup behaviour changed once you connected a 2nd monitor, maybe we need to double check this here again. I test and develop APP continously using 2 monitors and never experienced this issue myself.
Mabula
This post was modified 3 months ago 2 times by Mabula-Admin
@mabula-admin Where is the config written to? I have yet to find a file that contains the config, as @rouven has stated his console screen remains white, so he might not be able to click on the cfg option.
If you can share the location of the file that contains the config, he might be able to rename the file so that APP starts with default config. I have just tried removing APP, deleting all the associated folders within my user profile, and then re-installed APP and it still picked up my config 😀
I am also able to re-produce the issue of extremely long startup / not at all, after re-installing under "Only for me" rather than "Everyone" it took over 30 seconds to start this time:
@mabula-admin Where is the config written to? I have yet to find a file that contains the config, as @rouven has stated his console screen remains white, so he might not be able to click on the cfg option.
If you can share the location of the file that contains the config, he might be able to rename the file so that APP starts with default config. I have just tried removing APP, deleting all the associated folders within my user profile, and then re-installed APP and it still picked up my config 😀
I am also able to re-produce the issue of extremely long startup / not at all, after re-installing under "Only for me" rather than "Everyone" it took over 30 seconds to start this time:
@stastro, Actually, this is a diffent problem then... @rouvinho209 APP does start quick in only 3seconds, but the main window will simply not show...
In your case, OpenGL initialization takes such a long time, which is also weird... I will check if it takes longer for me as well if I install for Only me.
@mabula-admin I am also updating my 3080 drivers since they released a version with some bug fixes for Starfield, OpenGL is part of the driver package it seems.
Maybe it's time to also start thinking about CUDA for the NVidia side of the camp, as OpenGL is designed for AMD, I have done some extensive testing of CUDA in image processing especially with StarXterminator and BlurXterminator and the performance gain is phenominal, removing starts from a 286mpx image takes 45 min on the CPU, but 2.5 minutes on the GPU, I suspect a lot of the processes in APP would benefit hugely by handing it off to the GPU
@mabula-admin I am also updating my 3080 drivers since they released a version with some bug fixes for Starfield, OpenGL is part of the driver package it seems.
Maybe it's time to also start thinking about CUDA for the NVidia side of the camp, as OpenGL is designed for AMD, I have done some extensive testing of CUDA in image processing especially with StarXterminator and BlurXterminator and the performance gain is phenominal, removing starts from a 286mpx image takes 45 min on the CPU, but 2.5 minutes on the GPU, I suspect a lot of the processes in APP would benefit hugely by handing it off to the GPU
Let us first solve this startup problem 😉
In addition, rewriting things in CUDA will take a lot of work and this is definitely not friendly for anyone which does not have a Nvidia GPU.
I feel it is better to use a GPU method that will work on all GPUs. Then everyone can profit from invested work and time on GPU processing. Or does CUDA work these days on non-nvidia chips?
GPU processing should also work on GPUs that are attached to the CPU as well I feel like on Intel CPUs. We did tests with aparapi and we know it will speed certain tasks up greatly once implemented correctly. And we also know that behind the scenes, our main development platform might actually build GPU processing directly into their API leaving us with little work left once implemented 😉 GPU will definitely come into APP and major improvements for that might not be far away even.
OpenGL is not designed for AMD i think, is it? But more so for cross-platform i thought, lIke Vulcan, which is basically OpenGL further improved.
This post was modified 3 months ago by Mabula-Admin
@mabula-admin Because in the latest test version the console output window wasn't visible I deinstalled this version and reinstalled the beta23 version once again. But now I have the same issue with the console output window as with the APP window. It remains white in task bar and on a click on it nothing happens. I have no clue about IT, but I have the feeling the program won't be removed completely by deinstalling. Anywhere seems a temporary file to be loaded by the reinstalled version. But I can be completely wrong.
Here are my 2 tests, the first i started Photoshop to force it (very quickly) and the second I started Photoshop very late, cause it didn't show up it self.
You see the timestamps are looooong.
Hope you find the devil in the code.... I guess it's Windows... 🤣
So it would appear in all of the problematic startups (delayed) OpenGL seems to be the constant variable causing the issue. Now obviously this is not an APP issue, as APP just calls on OpenGL, APP does not control how quickly OpenGL launches, there could be many reasons for this such as another process locking OpenGL. My start time varies now, I can get as low as 2.37s startup, and sometimes is is >30s startup, but again it is always OpenGL being the root cause.
I have compared my OpenGL settings with @technohell, and apart from the NVIDIA driver (I updated yesterday), everything else is identical even though I am running Windows 11 Pro. So there seems to be some consistency there within OpenGL.
My platform Core i9 13900 128GB DDR5 PCIe Gen 5 M.2 SSD 2xP5800X in a RAID0 config as my APP Working location / Swap for Pixinsight NVIDIA 3080
I think with all the "Software" we have on our systems today, it's almost impossible to determine which one uses any fraction of OpenGL that could be causing an issue, the only way to fully validate is for a perfectly "Clean" system with just APP installed, and I am almost 100% that startup time would be perfect every time. But as you load more and more software, then some application/process would start to interfere with OpenGL and cause the delay in startup for APP.
@mabula-admin since you know a bit more about OpenGL than probably all of us on this thread put together, is there any way of troubleshooting / tracing OpenGL from an API perspective during APP launch?
Thank you very much for helping out here, indeed, this all points to an issue with our OpenGL dependency somehow on the windows platform. We use an external library called JOGL for this. And we have updated their library 2 times in the past couple of beta's. So maybe there is an initialization bug in there all of a sudden. I have tested this with the startup log on Linux and mac Intel and mac Apple Silicon, on those systems the OpenGL initialization is very fast, like 1-2 seconds only, giving APP startup time of only 2-3 seconds. But on my windows 10 machine it is always quite a bit slower, but the machine itself is the fastest of them all by alarge margin. OpenGL initialization on my windows 10 compueter is roughly 7 seconds all the time.
I will add more logging now to the OpenGL init part to see at what call it will actually stall. Maybe that indicates why Photoshop can all of a sudden trigger it to advance? And I will contact the JOGL developers upstream to see if they are aware of such an issue on Windows.
In addition to this particular problem, I am actually making an application startup dialog now to better show to the user that startup is taking place which should enhance user experience.
Please bare with me, I have been working a lot on this issue now, and I need to address other forum/email questions first now, but this one is a high priority to solve of course. Application startup should be smooth, fast and issue free 😉 !
Finally, I think i have found the cause of the startup delays. It does mean that the issue is caused by some security application or setting on your computers that blocks loading of native libs for OpenGL to load.
Especially company computers can have security implemented that causes these kind of issues.
But, there is definitely a workaround and it should improve APP startup time for everyone, so I will work on this now and will let you know as soon as possible when you can test again 😉
@mabula-admin care to share more information on the "Security" situation?
Is it
1. Software based 2. Hardware based like TPM for example 3. Anti-Virus Based 4. GPO Based
Mine is not a company computer so I have the luxury of playing around with settings if needs be
hi @stastro, I think it can occur especially with anti-virus/malware software and security scripts that are implemented by IT for company computers to not allow the employee to do bad stuff possibly.
@mabula-admin care to share more information on the "Security" situation?
Is it
1. Software based 2. Hardware based like TPM for example 3. Anti-Virus Based 4. GPO Based
Mine is not a company computer so I have the luxury of playing around with settings if needs be
hi @stastro, I think it can occur especially with anti-virus/malware software and security scripts that are implemented by IT for company computers to not allow the employee to do bad stuff possibly.
I have received information that Avira antivirus for instance will cause this slowdown. So please check if APP starts normally when you have disabled your antivirus scanner momentarily. If it starts normally then, then your antivirus is having a false positive here and you might want to add an exception for APP then. I will still try to fix it with a workaround 😉
@mabula-admin Rather than disabling my AV, can you provide a list of Locations to be added as an exception to my AV, I am using Sophos so I can add folders as well as Executables. I have just added the following to be excluded from real time scans
Despite doing that, it still took a long time to load:
This post was modified 3 months ago 2 times by Simon Todd
@mabula-admin Rather than disabling my AV, can you provide a list of Locations to be added as an exception to my AV, I am using Sophos so I can add folders as well as Executables. I have just added the following to be excluded from real time scans
@stastro You would simply use the APP installation folder and APP's executable. I have checked on my computer, I use Bitdefender but disabling it does not reduce loading time of 6-7 seconds. We also do not have reports Sophos is a problem.
Avira is known for problems like this it seems, it is a free package and seems to give many false positives. Maybe it is not even related to our issue. I am still not completely sure what is going on.
@mabula-admin You might be onto something and it might not be the APP app with the AV
I temporarily disabled real time protection completely, and startup time was always around 4 seconds in total, and I repeated this multiple times. I then went and re-enabled real time protection, and straight away the first launch of APP took 11.45 seconds and again OpenGL is the culprit, so maybe exceltions need to be in place for OpenGL runtimes, but I think this would be a very risky security hole, as any application could then take advantage of OpenGL runtime libraries and a potential malicious code attack could take place.
Realtime Protection Disabled Run 1: 4.04 seconds Run 2: 4.70 seconds Run 3: 4.15 seconds Run 4: 4.45 seconds Run 5: 4.92 seconds Run 6: 4.49 seconds Run 7: 4.53 seconds Run 8: 4.06 seconds Run 9: 4.20 seconds
Realtime protection enabled (with exception for APP folder in place), the longer the gap is between launching instances, the more time it takes to load Run 1: 17.14 seconds Run 2: 4.82 seconds Run 3: 5.72 seconds Run 4: 6.30 seconds Run 5: 8.78 seconds Run 6: 12.84 seconds Run 7: 9.64 seconds Run 8: 15.78 seconds Run 9: 13.45 seconds
After running Process Monitor, and filtering out all the background noise when APP is not running, I have tied the issue down to it being java.exe and javaw.exe related. In my last launch at 17:05:25 only java.exe and javaw.exe processes were active, all the way through to 17:05:30 when OpenGL had completed initialization. So whilst the issue seems to be OpenGL related, I think we might need to look at Java too. Asside from SmartScreen creating a thread then closing it, there's nothing else.
I confirm Marvin's suggestion, it's a known problem: jogamp.org/bugzilla/show_bug.cgi?id=1301#c7 I remind that JOGL itself isn't to blame. Some virus scanners find JogAmp's automated native library extraction suspicious and take ages to scan the extracted libraries (which seems to be your problem). Sometimes, it's rather IOUtil.testDirExec() that takes a long time. Actually, the automated native library loading is a nice feature, it eases the deployment a lot but it's almost useless when you build your native bundles for a "polished" software under your control.
The explanation is that the native libs that JOGL needs to init OpenGL are currently unzipped from a jar archive and then loaded. This unpacking is the issue, it triggers a scan of the archive and various security package will do this, some might even block it apparently allthough the inside of the archive has no security threat.
So this is what I am working on right now actually, prevent the unzip operation and provde JOGL a location where the native libs are already unpacked and ready to be loaded into java's virtual machine.
If we are right, it should definitely solve the issue for the users where startup time is soo long.
Mabula
This post was modified 3 months ago 2 times by Mabula-Admin
Allright, I have things working now with a workaround for the OpenGL slow load issue on windows. I should be able to give you a new test version tomorrow 🙂 !
Finally, I have a new test version for you now 2.0.0-beta24-test3.
Unfortunately, I ran into some issues yesterday so could not supply it yesterday as promised.
This test version has the workaround for the OpenGL/JOGL library, and should prevent the slow or not loading of AstroPixelProcessor due to OpenGL initialization I think.
On most systems this version will load a bit faster in general as well, this issue helped me with analysing application startup and I have now added again a startup window that should actually function now.
When the application has started, a dialog will show the complete startup log and more information about the OpenGL initialization has been added. That dialog is still shown for testing purposes of this issue. I will remove it when the issue is solved. Finally, the startup log will always be printed now in the general console, so after each APP start, everyone can see the startup log in there.
Oh, last modification, the license check has been placed earlier in the application startup. So if the license check is vaild, you will not even see a message dialog at startup about license verification. Only when the license check fails, a window will popup about this when the application has started. So that improves startup time as well 😉
Please test this version and let me know if the slow application start on windows is solved now :
