1. 10 Mar, 2017 1 commit
  2. 02 Sep, 2016 1 commit
    • Ken Thomases's avatar
      winemac: Set windows to transparent until they have content to draw, to reduce flicker. · fdd7db05
      Ken Thomases authored
      When a window is shown, it may not have drawn its content into the backing
      surface, yet.  Cocoa will draw the window, starting with its standard light
      gray background and then the content view.  However, the content view won't
      have anything to draw, yet, though, so the window background is not drawn over.
      
      A short while later, usually, the app will paint its content into the window
      backing surface and Cocoa will be told to redraw the window.  This works, but
      the user can often see the flash of the window background color first.  This
      is especially visible for windows with dark content.
      
      Part of the fix is to set the window background to transparent until the
      content view has actually drawn once since the window was shown.
      
      That's not sufficient on its own, though.  We had disabled Cocoa's automatic
      display mechanism for windows and put display on a display-link timer.  This
      meant that the window was not actually cleared to its transparent color.  When
      the window was shown, the Window Server displayed a white backing buffer.  It
      is the app process which should fill that backing buffer with clear color but,
      because we had disabled auto-display, that wasn't getting done at the same
      time the window was displayed.  It was happening some time after.  Again, the
      result was a visible flicker of white.
      
      So, we now temporarily re-enable auto-display just before showing a window.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      fdd7db05
  3. 06 May, 2016 1 commit
    • Ken Thomases's avatar
      winemac: Add support for a high-resolution ("Retina") rendering mode. · 1c94bf39
      Ken Thomases authored
      When this Retina mode is enabled and the primary display is in the user's
      default configuration, Wine gets told that screen and window sizes and mouse
      coordinates are twice what Cocoa reports them as in its virtual coordinate
      system ("points").  The Windows apps then renders at that high resolution and
      the Mac driver blits it to screen.  If the screen is actually a Retina display
      in a high-DPI mode, then this extra detail will be preserved.  Otherwise, the
      rendering will be downsampled and blurry.
      
      This is intended to be combined with increasing the Windows DPI, as via winecfg.
      If that is doubled to 192, then, in theory, graphical elements will remain the
      same visual size on screen but be rendered with finer detail.  Unfortunately,
      many Windows programs don't correctly handle non-standard DPI so the results
      are not always perfect.
      
      The registry setting to enable Retina mode is:
      
      [HKEY_CURRENT_USER\Software\Wine\Mac Driver]
      "RetinaMode"="y"
      
      Note that this setting is not looked for in the AppDefaults\<exe name> key
      because it doesn't make sense for only some processes in a Wine session to see
      the high-resolution sizes and coordinates.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      1c94bf39
  4. 10 Nov, 2015 1 commit
    • Ken Thomases's avatar
      winemac: Stop the CVDisplayLink when there are no more changes to flush. · b4fc81bd
      Ken Thomases authored
      The change to a CVDisplayLink-driven display mechanism introduced a problem: a
      Wine process never went completely idle for long periods.  The display link
      would fire for every refresh cycle of the display, waking a CPU from idle and
      wasting energy.
      
      To fix that, I have the display link stop itself when it determines that none
      of its windows need to be displayed.  When a window is subsequently marked as
      needing display, it either temporarily re-enables Cocoa's normal autodisplay
      mechanism so that it displays at the end of the current turn of the run loop,
      or it restarts the display link.  It chooses the former if it's been a long
      time since the window was last displayed so that the display is done more
      immediately.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      b4fc81bd
  5. 06 Nov, 2015 2 commits
    • Ken Thomases's avatar
      winemac: Remove the live-resize display timer. · bb44de78
      Ken Thomases authored
      It's redundant with the new CVDisplayLink-driven display mechanism.
      
      This reverts commits d55d2ec8 and 94dc91a4.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      bb44de78
    • Ken Thomases's avatar
      winemac: Use CVDisplayLink to limit window redrawing to the display refresh rate. · 3beec95a
      Ken Thomases authored
      Some Windows apps cause user32 to flush the window surface much faster than the
      display refresh rate.  The Mac driver only marks its window as needing to be
      redrawn and lets Cocoa decide how often to actually redraw.  Unfortunately,
      Cocoa redraws each time through the run loop and, since the Mac driver uses a
      run loop source to convey messages from background threads to the main thread,
      it redraws after every batch of messages.
      
      On some versions of OS X, this excessive drawing provokes synchronization with
      the window server's buffer swaps, preventing the main thread from being
      responsive.  Even when that doesn't happen, it's wasteful.
      
      So, we set our windows' autodisplay property to false so that Cocoa never
      displays windows itself.  Then, we arrange to call -displayIfNeeded once per
      display refresh cycle using a CVDisplayLink.  We maintain one CVDisplayLink per
      display (on demand), move windows among them as the windows change screens,
      start them when they acquire their first window, and stop them when they have
      none left.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      3beec95a
  6. 23 Oct, 2015 1 commit
    • Ken Thomases's avatar
      winemac: Use a snapshot of an owned window when a zero-sized owner window is minimized. · 496b001a
      Ken Thomases authored
      Some apps create a zero-sized window as their "main" window and then create
      all of the other top-level windows as owned windows with that main window as
      the owner.  The user interacts with these owned windows.  When the user
      attempts to minimize one of these owned windows, the app instead minimizes the
      zero-sized owner window.  When an owner window is minimized, all of its owned
      windows are hidden.
      
      The Mac driver faithfully carries out these window operations.  The only
      visible windows are hidden and the zero-sized window is minimized.  This
      results in an invisible animation of the window down to a slot in the Dock -
      a slot which appears mostly empty.  The invisible window thumbnail is badged
      with the app icon, but it still looks strange.
      
      On Windows, the Alt-Tab switcher uses the image of the owned window to
      represent the zero-sized owner.
      
      This commit attempts to do something similar.  It takes over drawing of the
      Dock icon for minimized, zero-sized window.  It grabs a snapshot of one of the
      owned windows and draws the app badge onto it.  Since the owned windows are
      hidden before the zero-sized owner is minimized and we can't take snapshots of
      hidden windows, we use heuristics to guess when it may be useful to grab the
      snapshot.  If the user minimizes an owned window from the Cocoa side, we grab
      that window's snapshot.  If an owned window is being hidden and no snapshot has
      been taken recently, we grab its snapshot on the theory that this may be the
      beginning of hiding all of the owned windows before minimizing the owner.
      
      Unfortunately, this doesn't address the invisible animations when minimizing
      and unminimizing the zero-sized owner window.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      496b001a
  7. 24 Mar, 2015 1 commit
    • Ken Thomases's avatar
      winemac: Restore a maximized window if a user tries to move it by dragging its title bar. · 792b47ad
      Ken Thomases authored
      OS X doesn't have the same concept of maximized windows as Windows does.
      There's no mode that prevents a normally-movable window from being moved.  If
      a window is "zoomed", it mostly fills the screen but the user can still move
      or resize it, at which point it ceases to be in the zoomed state.  So, users
      are confused and frustrated when they can't move a window that's maximized.
      
      To get similar behavior while still respecting Win32 semantics, we detect when
      the user tries to move a maximized window.  When they start, a request is
      submitted to the app to restore the window.  Unless and until the window is
      restored, we don't actually allow the window to move.
      
      The user expects to move the window from its current (maximized) position.  It
      should not jump to its normal position upon being restored.  So, we set the
      window's normal position to its current position before restoring it.
      792b47ad
  8. 03 Oct, 2014 1 commit
  9. 29 Apr, 2014 1 commit
  10. 24 Apr, 2014 1 commit
  11. 31 Dec, 2013 1 commit
    • Ken Thomases's avatar
      winemac: Track whether our windows would be visible if the process weren't hidden. · ae473236
      Ken Thomases authored
      The -[NSWindow isVisible] method returns FALSE when the process is hidden,
      but that's not what we need to know in some cases.
      
      This fixes full-screen games which minimize their window when they lose
      focus.  Command-Tabbing away hides the process.  Because the window was not
      visible, the code didn't actually minimize it.  When switching back to the
      process, no event was sent to the Wine back-end telling it the window had
      been restored, so it never resumed drawing to it.
      ae473236
  12. 30 Dec, 2013 1 commit
    • Ken Thomases's avatar
      winemac: Implement support for maximizing windows. · 66736b4a
      Ken Thomases authored
      The user is prevented from moving or resizing a maximized window.  The zoom
      button is still present and enabled for a maximized window but requests that
      it be restored rather than simply resizing it, which is what it does for
      normal windows.
      
      If a window is not resizable (lacks WS_THICKFRAME) but has a maximize box
      (WS_MAXIMIZEBOX), then the zoom button requests that it be maximized rather
      than resizing it.
      66736b4a
  13. 15 Nov, 2013 1 commit
  14. 11 Oct, 2013 1 commit
  15. 08 Oct, 2013 1 commit
  16. 30 Sep, 2013 1 commit
  17. 27 Sep, 2013 1 commit
  18. 26 Sep, 2013 1 commit
    • Ken Thomases's avatar
      winemac: When programmatically focusing a window, don't generate… · 4e0e9ca8
      Ken Thomases authored
      winemac: When programmatically focusing a window, don't generate WINDOW_LOST_FOCUS event for previously focused window.
      
      That event can confuse things if the program switches focus from A to B and
      then back to A and then processes events.  It will get an event saying that
      A lost focus in Cocoa, check that A does indeed have current focus in Wine,
      and so switch focus away from it (to the desktop window).  (It then gets an
      event that B lost focus, but that does nothing at that point.)
      4e0e9ca8
  19. 18 Sep, 2013 1 commit
  20. 30 Aug, 2013 1 commit
  21. 09 Jul, 2013 2 commits
  22. 28 Jun, 2013 1 commit
  23. 18 Jun, 2013 1 commit
  24. 07 Jun, 2013 1 commit
  25. 04 Jun, 2013 1 commit
  26. 17 May, 2013 1 commit
  27. 14 May, 2013 1 commit
  28. 07 May, 2013 1 commit
  29. 22 Apr, 2013 1 commit
  30. 02 Apr, 2013 1 commit
  31. 25 Feb, 2013 1 commit
  32. 18 Feb, 2013 2 commits
  33. 07 Feb, 2013 1 commit
  34. 05 Feb, 2013 2 commits
  35. 28 Jan, 2013 2 commits