Commits on May 28, 2024

1. Fix lapce#463 - broken inter-window update messages …

   This addresses a couple of issues:
   
    * Messages (including repaints) not getting processed when delivered a `View` in a window which is inactive
    * Ability to retrieve the window id of a view without the application having to pass that information down
      to whatever code needs it
   
   and addresses a related issue - obtaining a `WindowId` for a realized `View` and its bounds on screen, in order
   to convert view-relative locations into screen locations for purposes such as positioning windows relative
   to a `View`.
   
   This patch adds a tracking data structure, and a convenience data structure which contains sufficient
   information to convert view-relative positions to screen-positions and back.
   
    * A static mapping of `root-id:WindowId`:`Arc<Window>` which is populated on window creation and cleared on destruction,
     which makes it possible to access `Window.request_redraw()` to force a redraw.  It is guarded by a read-write
     lock (but written to only during window creation and destruction).
    * `ScreenLayout` contains a snapshot of the window id, the window's content and framed bounds, the view's
     origin within the window and the monitor scaling.
   
   So, a ViewId that wants its window-id looks up its root view's id, and looks up the WindowId associated
   with that root.
   
   We extend `WindowId` with methods to get the window bounds on screen with and without decorations and similar -
   these methods could be added to `ViewId` instead, but it seems more intuitive that you ask a window id for
   the window's bounds the same way you ask a view id for the view's bounds - that seems like what users will
   expect.
   
   Given the usage patterns (the mapping will only be locked for writing when a window is being created or destroyed, and will
   not be read-locked except in the case of forcing a repaint or looking up window coordinates), it is not touched
   in the critical path of rendering - unless the application and destroying many windows at the same time on
   different threads, I would not expect the read-write lock to be contended at all in practice (famous last
   words, I know).
   
   A thread-local for the mapping, as is done in `update.rs` might work (or look like it works), but we would be
   assuming no platform floem will ever support uses different event threads for different windows' event
   loops. I know of two that do - BeOS and Java AWT (with its stack of event threads to allow modal dialogs
   that work when their parent is disabled or blocked, which was a source of "interesting" deadlocks).
   
   If there was some path that I missed that would let a `ViewId` reach down to the `WindowHandle` that
   owns it without doing this sort of tracking, I would love to know about it - `PaintCx` has this information,
   but it is the only thing that does, and the `ViewId` has no access to it.

   

   timboudreau committed May 28, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 6ab4d1f
   • Browse repository at this point

   Copy the full SHA

   6ab4d1f View commit details

   Browse the repository at this point in the history