point_transformer.h 3.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475
  1. // Copyright 2014 The Chromium Authors. All rights reserved.
  2. // Use of this source code is governed by a BSD-style license that can be
  3. // found in the LICENSE file.
  4. #ifndef REMOTING_HOST_CHROMEOS_POINT_TRANSFORMER_H_
  5. #define REMOTING_HOST_CHROMEOS_POINT_TRANSFORMER_H_
  6. #include "ui/gfx/geometry/point_f.h"
  7. namespace aura {
  8. class Window;
  9. } // namespace aura
  10. namespace remoting {
  11. // This class performs coordinate transformations between the different
  12. // coordinate systems used in ChromeOS.
  13. //
  14. // To understand the different coordinate systems, you must understand the
  15. // following concepts:
  16. //
  17. // Screen vs window coordinates:
  18. // * Window coordinates are relative to a given window. So 2 different
  19. // windows both have a 0x0 coordinate.
  20. // Because each physical display has its own root window, window
  21. // coordinates can also be used to express coordinates relative to a
  22. // display.
  23. // * Screen coordinates are absolute. Each root window is placed at a
  24. // different, non-overlapping place in the screen. This way screen
  25. // coordinates are 'globally unique', meaning that they can uniquely
  26. // identify any location in any root window.
  27. //
  28. // DIP vs pixels:
  29. // * Pixel coordinates use the physical pixel location of windows/displays.
  30. // This means a screen with physical resolution 3000x2000 will always have
  31. // a size of 3000x2000 in pixel coordinates, even if the screen is rotated
  32. // or uses a different scale factor (to make things look bigger).
  33. // * DIP coordinates use Device-Independent-Pixels, which is something that
  34. // can be changed in the software to make items on the screen look bigger
  35. // or smaller. So a screen with physical resolution 3000x2000 and a scale
  36. // factor of 2 will have a DIP resolution of 1500x1000.
  37. // DIP coordinates also take rotation into account, so if the above screen
  38. // is rotated 90 degrees in the software, it will have a DIP resolution of
  39. // 1000x1500.
  40. //
  41. //
  42. // These 2 concepts are orthogonal and can be combined, resulting in 4 different
  43. // coordinate systems:
  44. // * Screen DIP: Globally unique coordinates that take rotation and scale
  45. // factor into account. This is the system the user intuitively expects,
  46. // and what the user sees in the display settings.
  47. // * Screen Pixel: Globally unique coordinates that represent the physical
  48. // pixels of each display. This is what is used by the SystemInputInjector
  49. // class.
  50. // * Window DIP: Coordinates relative to a given window (display) that take
  51. // rotation and scale factor into account.
  52. // * Window Pixel: Coordinates relative to a given window (display) that
  53. // match the physical pixels of the display. This is used by the event
  54. // processing pipeline (i.e. the ui::PlatformEvent).
  55. //
  56. // All methods use floating points to minimize the rounding errors when
  57. // transforming between the different coordinate systems.
  58. class PointTransformer {
  59. public:
  60. static gfx::PointF ConvertScreenInDipToScreenInPixel(
  61. gfx::PointF location_in_screen_in_dip);
  62. static gfx::PointF ConvertWindowInPixelToScreenInDip(
  63. const aura::Window* window,
  64. gfx::PointF location_in_window_in_pixels);
  65. };
  66. } // namespace remoting
  67. #endif // REMOTING_HOST_CHROMEOS_POINT_TRANSFORMER_H_