|
Post by Stefan on Dec 1, 2022 13:57:54 GMT -5
George,
I've noticed this with v2.7.22333 and now 22335.
(1) Screen redraws.
Subjectively, start-up seems to take a fair bit longer.
Maybe that's also why there is a noticable pause between two distinct initial screen draws of the eventual display screen. This is even more obvious when SPFLIte draws the screen the first time in non-maximised size and then immediately replaces it with the maximised size.
(2) There's an issue with SET entries following startup. They are not 'enabled' until the user explicitly enters the SET command followed by END. eg: a SET entry like ALIAS.L=LOCATE TOP will not work until AFTER the user enters the SET command followed by END
|
|
|
Post by George on Dec 1, 2022 15:42:44 GMT -5
Stefan: The SET stuff not working was a dumb typo, corrected. Triggered by the changes to add comment support.
The screen re-draws are much tougher. At startup, Windows calls multiple times, for Initialization, for re-size (even though no resize was really done and for Tabs being given control and losing control. I honestly doubt I can correct this. Some is probably my own lack of Windows knowledge, especially when multiple tabs are opened. But SPFLite grew from a single, simple Cmd window with no tabs, into a proper Windows dialog, and then into multiple tabs. Each was done as I learned stuff, and migrated the code base onward. It could probably be done much better if starting over, but that's never going to happen.
I know from walking code through debug that screen redraws occur much too often during normal processing, but I'm loath to touch stuff for fear of triggering some other weirdness.
I'll post a new Beta tomorrow for the SET problem.
George
|
|
|
Post by Stefan on Dec 2, 2022 6:07:08 GMT -5
George,
This is a 'windowed' vs 'maximised' issue.
At startup, SPFLite opens the normal window twice, usually the two completely overlay each other EXACTLY and you hardly notice apart from a flicker. However, it becomes VERY noticable when the two window do NOT open in the same place on the display. This happens if the SPFLite window was 'maximised' at the time SPFlite is closed.
To provoke this, follow this sequence: (1) Open SPFlite and resize its window to occupy a rectangle in the centre of the display screen. (2) Close SPFlite. Every subsequent time you start SPFLIte, the window will open in the same place on the display screen. It's drawn twice but you hardly notice except for the flicker. (3) Open Spflite, and this time MAXIMISE (normal Windows icon in TITLE bar) the window to the display screen. (4) Close SPFLite Every subsequent time you start SPFLite, the window will be drawn 'windowed' first, and then be redrawn 'maximised'.
I'm guessiing... - SPFLite maintains two sets of window co-ordinates, one for "Windowed" and one for "Maximised", so it can return to previous 'windowed' view when a user switches out of 'maximised' view. - It should just pick the 'most recently used one' on startup, but it's always picking 'windowed' followed by 'most recently used'. Perhaps that's deliberate to allow you to get font sizes, etc and thus unavoidable.
|
|
|
Post by George on Dec 2, 2022 11:37:48 GMT -5
Stefan: Well, it's tough to work on this, on my system, the normal window seems perfect, no blink. The Max window, well, maybe once in 3-4 tries there MAY be a blink, but I can't even be sure of that.
I'm not doubting you, it just makes it hard to even try a change when nothing apparently seems to make any difference.
The next Beta will have a small attempt included, let me know if it helps at all.
Just FYI my system is Win 10 64bit, Intel i5, 6 core @ 2.6 GHz, 12 Gb memory. The graphics is nothing special, NVIDIA GT 1030 - 2 Meg
George
|
|
|
Post by Stefan on Dec 3, 2022 6:34:25 GMT -5
Hi George,
I reckon your machine is a fair bit quicker than my laptop. The forum limits attachments to 1MB per file, so I'll send you an email with a short video so you see what I see.
This is purely cosmetic and not worth a lot of effort.
I guess my question is - given the screen must be drawn twice at startup, why can SPFLite not draw the screen the right size both times?
|
|
|
Post by George on Dec 3, 2022 11:00:46 GMT -5
That's a good question. The very last thing it does before showing the dialog is to decide between normal and maximized.
Got your video, yes it's quite obvious on your system. I'll continue to poke around, it has to be something dumb I've overlooked.
Geprge
|
|
|
Post by George on Dec 3, 2022 13:34:53 GMT -5
Stefan: Try this one, I think (operative word is think) its better. George SPFLite2.2.7.22337.exe (492.5 KB) [UPDATE] 1st lets see if this IS any better, but regardless it's still not right, it tends to lose screen position and sizes as you go back and forth between normal and maximized. [/UPDATE]
|
|
|
Post by Stefan on Dec 4, 2022 7:21:34 GMT -5
Sorry - I cannot see a difference between 22336 and 22337 either.
I'll email you another video clip. This one was taken with v22337 and the camera in slo-mo mode. It shows the transitions more clearly. You know how many times you draw the screen. Maybe it's just my ancient (2012) hardware that makes a right song-and-dance to display the screen. I tried it both on the internal and the external screen and the sequence is the same.
|
|
|
Post by George on Dec 4, 2022 10:39:59 GMT -5
|
|
|
Post by Stefan on Dec 4, 2022 12:41:52 GMT -5
Hi George,
Version 22338 is improved and quicker to paint the window. I think this is acceptable and probably not worthy of more attention. The panel opening, whether 'windowed' or 'maximised', is smooth, especially bearing in mind I'm using a dark background for SPFLite, and most likely for the desktop too. This is bound to make it more noticeable that the window outline (white) is drawn first and then filled in dark with text. Windows for other applications typically remain with a white background when drawn so there's no 'white flash' to notice from the outline draw. When SPFLite inherits a 'maximised' window from the previous session, there is a clear double drawing of the screen. The first draws a SPFLite window (ouline and content) in the 'windowed' size and location which is then immediately replaced by a second drawing for the maximised window. As an aside, possibly related to your recent endeavours with the status bar.... Take another look at the first video (2022-12-03 10.19.24.mp4) I sent you. Notice the bottom right section of the STATUS BAR, when I maximised the screen. It think it should probably be blue.
I also think this is a temporary blip. You get the same effect if you slide the SPFLite right so part of it disappears off the right edge of the screen. When you 'slide' the window back, the SB is usually white, until the next ATTN event. I guess the SB is redrawn more frequently than I anticipated.
PS: Would love to hear your view about UP/DOWN MAX Revisited in Suggestions.
|
|