Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

BYE slow start up


tjensen7817

Question

16 answers to this question

Recommended Posts

  • 0
3 hours ago, astroman133 said:

Yes, but I would still like to be able to reduce the number of rows in a capture plan to further shorten the start up time.

<geek talk = ON>

That was actually not the issue after looking into it... well sort of.  The screen was repainted for each of the 100 rows as they were added... and this took more time as it went through the loop one by one with a repaint for each. 

To fix this I suspended the repaint in the control as they were added and the resumed the repaint only once all the 100 rows were added.  This reduced the amount considerably as only one paint event was fired.

In addition, I show the splash screen sooner in the start process.

</geek talk = OFF>

 

Link to comment
Share on other sites

  • 0

Thanks for the geeksplanation! <G> It makes perfect sense. Primitive Windows/controls design is not very optimum if it takes a lot of time to paint and repaint controls that are not even visible yet! I am so used to working with WPF where I do not bind controls to data until the form is displayed. This spreads out the initialization of various U/I forms so performance seems a lot more leveled.

On my 3.4 GHz quad core i7 desktop with over 5 GB of available memory, it still takes almost 10 seconds before I see the BYE main window. To me it seems like there is still quite a bit of room for reduction of the startup time.

Link to comment
Share on other sites

  • 0

Did these changes make it into 3.1.17?

I'm still getting at least a 30 second boot time to the main window on a desktop with Windows 7 Pro with and i7-4770 and 16GB, running from SSD.  It is (not surprisingly) slower on my imaging laptop.

Link to comment
Share on other sites

  • 0

Not in 3.1.7... but I've been working on this for the past 3 weeks... it turned into a major refactoring of the capture plan UI.  The next release should have some significant application load time performance to it.  Too early to tell how much but there will be a positive difference.

Regards,

Link to comment
Share on other sites

  • 0
On 6/26/2019 at 3:42 AM, admin said:

Not in 3.1.7... but I've been working on this for the past 3 weeks... it turned into a major refactoring of the capture plan UI.  The next release should have some significant application load time performance to it.  Too early to tell how much but there will be a positive difference.

Regards,

I just released 3.1.18 RC1 in the pre-release download section.  Please try it and compare the load time, you should see a positive difference.

Regards,

Link to comment
Share on other sites

  • 0
1 hour ago, AndrewS said:

I haven't had a chance to try it on my laptop, but the desktop startup time is substantially reduced.  It takes about 7 seconds, now. 

Thanks again, Guylain!

That's great Andrew, what was the time before on your computer?

A little bit of background...

BYE/BYN is event driven, including camera property values change events.  In the plan sequence there use to be 100 pre-loaded lines.  Each line have 3 camera properties, shutter, Av, and ISO.  That was 300 events fired and captured by the plan UI control... that is not a big thing usually... but all 300 events received required access to the UI thread to update the pulldown values... and that was the performance hog issue.

To fix this I did a few things. 

  1. I moved the event listener to the parent container control and updated all plan item rows at once, this brought down the event from 300 to 3.
  2. I have removed the 100 pre-loaded rows in favor of a user option to add rows at runtime as needed (premium only, classic edition is fixed to 20 rows).

These 2 changes made a huge difference.  When the application is loading, pay attention to the splash screen... it says loading..., initialize capture plan..., initialize Frame&Focus..., initialize Planetary..., etc....

The second step, initialize capture plan..., is where all the performance gain is as a result of these 2 changes.

 

Link to comment
Share on other sites

  • 0

I initially had times around 30 seconds.  I ran the original 3.1.17 before installing the release candidate, and it was around 21 seconds.  I'm not sure why it was quicker, today, other than I've probably rebooted since then.  I tend to have a lot of things running, and way too many tabs open in Chrome.

As I said, the RC was 7 seconds, but after exiting and running again, it's now taking about 4 seconds.

My laptop is quite a bit slower than my desktop PC, but I have not doubt this will also be a huge improvement, there.

I appreciate the detailed explanation of the changes.  I'm a programmer, so it's always good to hear of optimization methods.  :) 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use