Skip to content

Lots of work is duplicated when NonClientIslandWindow is resized and the drag bar size changes #1897

Closed

Description

This is work that's following on from work that's being done for #1625.

I'm pulling the code for updating the drag region out of NonClientIslandWindow::OnSize into its own method. Unfortunately, both these methods need to do the following block of work:

        const auto windowRect = GetWindowRect();
        const auto width = windowRect.right - windowRect.left;
        const auto height = windowRect.bottom - windowRect.top;

        const auto scale = GetCurrentDpiScale();
        const auto dpi = ::GetDpiForWindow(_window.get());

        const auto dragY = ::GetSystemMetricsForDpi(SM_CYDRAG, dpi);
        const auto dragX = ::GetSystemMetricsForDpi(SM_CXDRAG, dpi);

        // If we're maximized, we don't want to use the frame as our margins,
        // instead we want to use the margins from the maximization. If we included
        // the left&right sides of the frame in this calculation while maximized,
        // you' have a few pixels of the window border on the sides while maximized,
        // which most apps do not have.
        const auto bordersWidth = _isMaximized ?
                                      (_maximizedMargins.cxLeftWidth + _maximizedMargins.cxRightWidth) :
                                      (dragX * 2);
        const auto bordersHeight = _isMaximized ?
                                       (_maximizedMargins.cyBottomHeight + _maximizedMargins.cyTopHeight) :
                                       (dragY * 2);

        const auto windowsWidth = width - bordersWidth;
        const auto windowsHeight = height - bordersHeight;
        const auto xPos = _isMaximized ? _maximizedMargins.cxLeftWidth : dragX;
        const auto yPos = _isMaximized ? _maximizedMargins.cyTopHeight : dragY;

        const auto dragBarRect = GetDragAreaRect();
        const auto nonClientHeight = dragBarRect.bottom - dragBarRect.top;

Doing this twice is clearly ridiculous, and more likely than not, wrong.

I'm thinking that on the resize, we could probably just cache some of these values. I think this will also important for dealing with maximizing, cause I think know the maximize borders are wrong on non-primary displays.

Activity

  1. added
    Area-UserInterfaceIssues pertaining to the user interface of the Console or Terminal
    Issue-TaskIt's a feature request, but it doesn't really need a major design.
    on Jul 9, 2019
  2. ghost added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Jul 9, 2019
  3. Insomniak47 commented on Jul 13, 2019

    @Insomniak47

    Just wanted to pop in and confirm that your intuition re: Maximizing on non-primary windows is correct:
    I've got a portrait mode 1920*1080 monitor and when I maximize on it I lose the first character of my terminal prompt line

    Instead of
    C:\Users\Insomniak
    it's
    :\Users\Insomniak

    Local user mitigation is just to not maximize or do a half screen maximize and then just drag it out.

    I think that this is what you were mentioning but if that isn't the case let me know and I'll file a separate issue.

  4. DHowett-MSFT commented on Jul 14, 2019

    @DHowett-MSFT
    Contributor

    That one is known and fixed in the dev build 😄

  5. ghost added
    In-PRThis issue has a related PR
    on Nov 2, 2019
  6. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Nov 4, 2019
  7. added a commit that references this issue on Nov 4, 2019
    5dfc021
  8. ghost removed
    In-PRThis issue has a related PR
    on Nov 4, 2019
  9. ghost added
    Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.
    on Nov 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Area-UserInterfaceIssues pertaining to the user interface of the Console or TerminalIssue-TaskIt's a feature request, but it doesn't really need a major design.Needs-Tag-FixDoesn't match tag requirementsProduct-TerminalThe new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions