Jump to content

Search the Community

Showing results for tags 'highdpi'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Delphi Questions and Answers
    • Algorithms, Data Structures and Class Design
    • VCL
    • FMX
    • RTL and Delphi Object Pascal
    • Databases
    • Network, Cloud and Web
    • Windows API
    • Cross-platform
    • Delphi IDE and APIs
    • General Help
    • Delphi Third-Party
  • C++Builder Questions and Answers
    • General Help
  • General Discussions
    • Embarcadero Lounge
    • Tips / Blogs / Tutorials / Videos
    • Job Opportunities / Coder for Hire
    • I made this
  • Software Development
    • Project Planning and -Management
    • Software Testing and Quality Assurance
  • Community
    • Community Management

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Delphi-Version

Found 1 result

  1. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    Is it just my delphi applications that behave poorly when handling dpi changes? This is when setting high dpi in the manifest to PerMonitorV2. I have verified that the controls (many of them mine) are handling this as they should (override ChangeScale). When dragging the application between monitors with different dpi's, it takes 3-4 seconds while the window flickers and repaints multiple times - the dragging operation pauses while it does this, and then the window eventually jumps to where you actually dragged it. I've been looking at other applications (that ssupport PerMonitorV2) to see how they behave, even explorer stutters a little, due I guess to the ribbon control - but the stutter is around the 200ms mark. Thunderbird seem to repaint twice but very fast. After some debugging, as far as I can tell, this is caused by all controls getting their ChangeScale method called (as you would expect) which results in calls to SetBounds, which invalidates the control causing more painting! TWinControl.ScaleControlsForDpi appears to be doing the right thing (control alignment is a perf hog), but calling EnableAlign inevitably invalidates the control, again. procedure TWinControl.ScaleControlsForDpi(NewPPI: Integer); var I: Integer; begin DisableAlign; try for I := 0 to ControlCount - 1 do Controls[I].ScaleForPPI(NewPPI); finally EnableAlign; end; end; This really show up an inherent design flaw in the vcl, there is no BeginUpdate/EndUpdate design pattern in the vcl that allows a control (or form) to disable child controls painting until it's done. Many controls implement this pattern individually, but that doesn't help in this scenario. The situation isn't helped by my using Vcl Themes either - resize (setbounds) causes serious flicker in some controls and I'm sure this is coming into play here too. I tried to fudge a BeginUpdate/EndUpdate with this : procedure TMainForm.WMDpiChanged(var Message: TWMDpi); begin SendMessage(Self.Handle, WM_SETREDRAW, NativeUInt(False), 0); try inherited; finally SendMessage(Self.Handle, WM_SETREDRAW, NativeUInt(true), 0); RedrawWindow(Self.Handle, nil, 0, RDW_INVALIDATE or RDW_UPDATENOW or RDW_ALLCHILDREN); end; end; It cut's out the visible repainting, but doesn't speed things up much If anyone has any ideas on how to tackle this I'm all ears.
×