I've created padding of 77 pixels on the left of my screen ... then weirdness ensued.

1) The 'show more tray icons' popup is now offset vertically by about approx 5 pixels (it is drawn at the proper height initially, then it pop ups further vertically to its new position).

2) Certain applications (such as Adobe Reader DC, and Firefox), will open to their full size minus the padding on the left (correct) but will also have about 4 pixels of padding on the right (incorrect); selecting the max/restore titlebar button twice fixes this (and I've created a 'trigger' to do the same but it would be nice if all this weirdness wasn't there in the first place.

I have padding enabled as 77 pixels on the left side of the monitor - this allows a strip on the left side of my monitor for desktop access while in fullscreen (minus the strip) windows (such as FireFox maximized).

What occurs is the popup for the tray no longer renders at the appropriate height but what occurs is that it first renders at the proper height then immediately jumps up a few pixels.
see 'no padding tray' vs 'padding enabled tray'

Secondly, there are certain applications that when first opened maximized, there is a border on the right and bottom again for a few pixels; double clicking the title bar expands the window appropriately to the full right and bottom size WHILE keeping my 77 pixel padding on the left of the screen.

Problem persists on beta 6 ... (padding weirdness)

and now i have lag again ........ reverting to old stable version

Tray popup fixed in DF 9.7.1b7

The empty space on a full screen window is still apparent with Adobe Reader; Firefox seems to initially have the same problem but some quick window manipulation seems to fix the problem (similar fix to mine ... see below)

I previously used a program called MaxMax to preserve a section of my desktop as I am doing with DF now; the same weird spacing problem presents with MaxMax so this makes me wonder is this is resultant from some special window creation rather than a compatibility problem with DF.

My interim solution using DF's triggers (looks similar to what you're doing with Firefox)
Trigger waits for Window creation from process AcroRd32.exe
Wait 1000ms
Maximize window

so a more permenant and fully encompassing solution would be to identify what the uniqueness of firefox's and AcroRd32's windows are ...

another application that does the same weird padding problems as Firefox, Adobe acrobat is
paint.net
https://www.getpaint.net/

Using GUIPropView from NirSoft
https://www.nirsoft.net/utils/gui_prop_view.html

The programs that have the offset problem (as discussed above) seem to all have the same 'Style Value' in common (and other windows that don't have the padding problem use a different 'Style Value').

The 'Style Value' that has the padding problem is 16CF0000(hex) 382664704(dec).

No change with 9.7.1 Beta 8 regarding the padding problem
The fix that you implemented with Firefox still works, but other applications such as
paint.net
Acrobat Reader
Microsoft Edge (the latest version)
all have the same 'Style Value' that has the padding problem is 16CF0000(hex) 382664704(dec) and all have the weird padding problem

Edge Version 87.0.664.57 (Official build) (64-bit)
(yes, this problem was apparent with this version of MS Edge)

Debug log

Issue persists with DF 9.7.1b10

So how can I disable your window paddign "fix"?
Essentially you have the window go through what appears to me to be a seizure, then finally the window is set properly.

I used a trigger to watch for the window creation, then wait 1000ms, then do ONE "maximize" to set the window properly.

Hello Keith,
Using the default window movement fallback OR disabling this feature
makes no difference (both selections cause the window to preform the same jitter correction)

If I am the only one reporting this bug, then remove the code all together.
I have better UI control/fix with adding a trigger (wait 1000ms, maximize window).

It would be nice though to place a global window identifier (for triggers) with the 'style value' that I discussed above.

Sure thing Keith. Here is a video of Firefox opening with your fix (note the multiple attempts to correct the window placement).

The commonality that is associated with the programs/windows that display this aberrancy is that they all have a 'Style Value' of 16CF0000(hex) 382664704(dec).

Here is Adobe Acrobat opening with my fix (trigger of window created by process name, wait 1000ms, maximize window).

Note: only one correction required (not multiple as the Firefox fix)

and here is Paint.net opening with no fix
(note the space on the bottom and right sides of the screen)

Realistically Keith, if I am the only one reporting such a problem, then remove the code you created to fix Firefox and I can run individual triggers to correct the problem.

Thanks

OK - I hope the fix won't have the window going through a seizure process (as in my Firefox video); a simple detection with correction (one time; as with my trigger example) is an elegant fix until it can be determine why certain windows are opened offset.

Thanks!

I turned off my trigger for FF for the above purposes.
It seems that turning on the trigger takes presidence over the internal fix!
(the internal fix does not activate if there is a trigger)

This means that FF does not perform the multiple attempts to correct itself!

Now all I need is to have DF detect style values for windows (?)

['Style Value' that has the padding problem is 16CF0000(hex) 382664704(dec)]

The fix looks really great!
The padding issue is some inherent dysfunction within windows, but the fix is very quick and almost imperceptible.
Excellent!

Well the problem is back (don't know with what version it returned or if windows changed something).
The DF fix causes the window to shift position initially a few times but the result may or may not be in the correct final position.

I am thinking a better fix would be to:

Is window is in maximized state?
then check if window extends to top right corner ('screen size' - 'window x position' - 'window size')
if yes, then exit
if no, then maximize window

Sorry Keith,
10.0b13

Yes, the split is offset sometimes and sometimes not when FF starts.
Sometimes it corrects properly, and sometimes it corrects not properly (screen shifts then corrects, then shifts again to the first position).