Is it possible to make a gui without controls jittering/jumping when resizing?

[MiM]

---

---

Just to be safe i put all gif's in spoilers as they might cause epilepsy (?)
(they're not too flashy but i'd rather play it safe)

---

---

So for me, this:

Code: Select all

#SingleInstance, Force
Gui, +Resize
Gui, Color, Black
Gui, Add, Edit, w400 h200 vEditField
Gui, Show
Return
GuiSize:
GuiControl, Move, EditField, % "w" A_GuiWidth-20 " h" A_GuiHeight-10
Return

looks like this:
(gif makes it look much less jittery than it actually is in person)

but for my friend it looks like this:

I'm on Win8.1, my friend is on Win10
I don't think that has anything to do with this because the same thing happens for me on a Win10 virtual machine.
I'm not sure what causes that, my friend has a much better pc, i have an integrated GPU but a pretty good CPU.
(and to clarify, this doesn't happen ONLY to ahk GUI's, every window behaves like this)

There's a detailed explanation on this here.
I'm posting here hoping someone more experienced chimes in and explains stuff!

[RussF]

WARNING - personal opinions follow:

FWIW, I'm running on a Ryzen 7 5700G 3.8 GHz with NVidia 3060 GPU. Some of my windows jitter slightly when I resize them. Some do not. All the MS Office (2016) apps I tried do. Notepad++ does not.

Does it keep me up at night. Not in the least. In fact, I never really paid any attention to it until you brought it up. I've always just accepted it as part of Windows.

When I resize a window, I don't play with it like a yo-yo as in your examples. I resize it where I want and before I can even move the mouse to its next task, the screen has settled - less than 5 ms.

The topic has apparently been investigated quite a lot with no real resolution. It "appears" to be application specific rather than an OS issue, but even that is open to debate.

Since the source code for Notepad++ is available, perhaps you could comb through the thousands of lines of code and see how they handle window resizing without jittering. You could be a hero for the 0.01% of people that this apparently bothers. For the 99.99% of the rest of us, however, it's just not a big deal.

Respectfully submitted,
Russ

[MiM]

WARNING - personal opinions follow:

FWIW, I'm running on a Ryzen 7 5700G 3.8 GHz with NVidia 3060 GPU. Some of my windows jitter slightly when I resize them. Some do not. All the MS Office (2016) apps I tried do. Notepad++ does not.

Does it keep me up at night. Not in the least. In fact, I never really paid any attention to it until you brought it up. I've always just accepted it as part of Windows.

When I resize a window, I don't play with it like a yo-yo as in your examples. I resize it where I want and before I can even move the mouse to its next task, the screen has settled - less than 5 ms.

The topic has apparently been investigated quite a lot with no real resolution. It "appears" to be application specific rather than an OS issue, but even that is open to debate.

Since the source code for Notepad++ is available, perhaps you could comb through the thousands of lines of code and see how they handle window resizing without jittering. You could be a hero for the 0.01% of people that this apparently bothers. For the 99.99% of the rest of us, however, it's just not a big deal.

Respectfully submitted,
Russ

At least i know that it doesn't bother you, thanks!

[RussF]

Works for me:

explorer_0EUpeGaWC3.gif (1.36 MiB) Viewed 1714 times

Russ

[MiM]

@RussF
I'd appreciate it if you read my whole post before commenting, i'm gonna leave it at that, thank you!

[wetware05]

What a fun game.

Do you realize that one thing is what you see on your computer, another thing is how it will look in a gif, and another thing is how each person will see the gif, according to their own computer? Too many variables at stake, complexity comes into play.

I forgot to add each person's age and vision quality, and how tired they are. The older you are, the more intermediate steps are lost to vision. The more tired the same. One more fact. With a high level of adrenaline, more information is seen (as it happens to avoid an accident that can be fatal). The calmer, the fewer frames are seen.

[RussF]

With all due respect @MiM, I DID read your entire post, followed the link you provided as well as some of the links from it as well as a Google search.

My point is that even though this happens on most machines and with many apps, it has apparently has only been a problem for a very small number of people. It's been this way for a very long time with no finite solution (that I could find) to date.

I've been in the I.T. field over 40 years and I have yet to have anyone ask me, "Why does my window flicker when I resize it?" People accept that it's just the way it is and move on. There are some, of course, who will spend an enormous amount of time chasing this windmill. I have already spent more than I care to, but by all means, please continue your research.

Best regards,

Russ

[MiM]

@RussF

(and to clarify, this doesn't happen ONLY to ahk GUI's, every window behaves like this)

and you proceeded with claiming

Since the source code for Notepad++ is available, perhaps you could comb through the thousands of lines of code and see how they handle window resizing without jittering.

So i doubt you've read my entire post or perhaps you did read it but not with UNDERSTANDING.
I'm also gonna take a wild guess that you just glanced for less than 10 seconds at the post i've linked since you've stated

You could be a hero for the 0.01% of people that this apparently bothers. For the 99.99% of the rest of us, however, it's just not a big deal.

and the post i've linked states in BOLD at the very tippy top:

It is not an understatement to say this Windows problem has driven thousands of app developers crazy.

I'm not gonna humor you further.

[RussF]

Ahh, yes, and apparently you failed to read the first line of my first post,

WARNING - personal opinions follow:

Hope you have a wonderful day.

Russ

[FanaticGuru]

Short answer: Yes
Longer answer: Yes, I feel confident it is possible with enough time, money, and resources but it is practically impossible.

I doubt you are going to find a solution to a Windows problem on an AutoHotkey board. It seems to be a problem that no one has posted a googlable solution to anywhere on the internet.

It does seem to me to be a combination of application and hardware. Some programs do it much worse than others. The higher end my computer the less it seems to manifest in general. Resolution, scaling, refresh rate, hardware graphic processing, all seem to have an effect. Like I would expect, the quality of the results appears to be a combination of code efficiency and the power running the code.

So, maybe modifying AutoHotkey's base code could improve the results for AutoHotkey's GUIs but probably not without creating custom resizing code instead of passing it all off to Windows.

I have never heard anyone complain about it before, so it is probably ranked very low on Microsoft's list of improvements. The way some things slide a little out of place and then slide back, it is almost as if part of the effect is intentional. Maybe to cover up something that looks even worse. I just view it as a 'feature' of Windows to let you know the window is in flux.

FG

[MiM]

@FanaticGuru
Yeah i understand that it happens for a reason, my guess is that they chose this jittering instead of resizing of the window being "slower" like, i think there is a way to... it's kinda hard to explain but bare with me, when user drags to resize the window, the window wouldn't immediately snap to the mouse position, instead it would calculate the desired positions of controls inside the window, it would place them accordingly (without repainting the window) and only THEN the actual window would get resized. (I've explained it pretty badly but hopefully it's understandable...)

The more technical explanation:
as the thread i posted states -

During the processing of those messages (shortly after WM_WINDOWPOSCHANGING returns), Windows makes an internal call to SetWindowPos() to actually resize the window. That SetWindowPos() call first resizes the non-client area (e.g. the title bars and window border) then turns its attention to the client area (the main part of the window that you are responsible for).

So, is it technically possible to "sync" the client area resizing with the non-client area resizing?
(or perhaps, delay the non-client area resizing)

I personally would probably never find a "nice" solution, the most i could muster would be some wonky work-around.

Now i'll bore you with some things i've messed around with:

---

Let's take the first code i posted ~

Code: Select all

#SingleInstance, Force
Gui, +Resize
Gui, Color, Black
Gui, Add, Edit, w400 h200 vEditField
Gui, Show
Return
GuiSize:
GuiControl, Move, EditField, % "w" A_GuiWidth-20 " h" A_GuiHeight-10
Return

it behaves (FOR ME) like this

But for some odd reason, this ~

Code: Select all

#SingleInstance, Force
Gui, +Resize
Gui, Color, Black
Gui, Add, Edit, w400 h200 vEditField +hwndEditFieldHwnd
WinSet, Transparent, 255, ahk_id %EditFieldHwnd%
Gui, Show
Return
GuiSize:
GuiControl, Move, EditField, % "w" A_GuiWidth-20 " h" A_GuiHeight-10
Return

(added WinSet, Transparent, 255, ahk_id %EditFieldHwnd%)
looks like this

---

In my personal opinion, the second way looks better.

And here's a funny find ~

Code: Select all

#SingleInstance, Force

Gui, +AlwaysOnTop +Resize
Gui, Color, ffffff

Gui, Add, StatusBar, +hwndSBHwnd -Theme -0x400000
SendMessage, 0x408, 100, 0,, ahk_id %SBHwnd% ; Change status bar height.
Gui, Add, Progress, x0 y0 w10000 h102 +hwndPHwnd +Backgroundblue ; A wonky solution to get a solid color for the statusbar.
DllCall("SetParent", Ptr, PHwnd, Ptr, SBHwnd) ; SetParent progress to statusbar.

Gui, Add, Button, x5 y5 h30 +hwndBHwnd vButtonLabel, Hello!
DllCall("SetParent", Ptr, BHwnd, Ptr, PHwnd) ; SetParent button to progress.

WinSet, Transparent, 255, ahk_id %SBHwnd% ; For some odd reason, this causes the statusbar to not jump around nearly as much.
Gui, Show, w500 h500
Return


GuiSize:
GuiControl, Move, ButtonLabel, % "w" A_GuiWidth-10 ; Move button
Return

I've commented most stuff, again it uses the WinSet, Transparent weirdness but this time with a statusbar.
it looks like this

And if the statusbar is right-justified or whatever, the jittering/jumping stops horizontally instead of vertically.

Keep in mind that the gif's don't 100% represent how it looks for me in person, in person there's much more jittering/jumping
EXCEPT the statusbar method, it's almost as smooth as the gif, there's no "jittering" but it rarely "jumps"

Anyways i just posted these for fun, they're not real solutions to this problem because for my friend (with the better pc), the statusbar method is insanely jittery/jumpy and the statusbar sometimes even pokes out the bottom of the window when it jumps so yeah

I realize there's not much of a point me posting the code and stuff since not many people can test it out because again, only "worse pc's" have this problem but i like messing around with this kind of stuff

[iseahound]

The default styles CS_HREDRAW | CS_VREDRAW are the culprit. Make your own class, I do this in all my projects.