. instead of Control:hCursor, make cursor be part of the style.
  This is more css-like and we'll make Control smaller

. make it easier to create HWND backing HwndWrapper()

. combine Button and ButtonVector into one

. introduce a concept of drawable, which would be
  lighter-weight than a Control and could be used
  to do html layout (i.e. make html layout we do
  for ebooks also available as part of mui).

. add more tests for testing various features e.g. Grid colSpan etc.

. a way to easily do text selection in generic way in EventMgr
by giving windows a way to declare they have selectable text/elements

. some claim GDI+ text drawing is slower than GDI, so we could try
to use GDI instead

. Grid: add support for laying out elements in
  cells in the same row by baseline (for text)
  Use a magic value for ElAlignData (e.g. -1.f, -1.f)
  when it's used as horizAlign

. instead of making tooltip just WCHAR*, make it an arbitrary
  Control, for greater creative control

. use anti-graint library for graphics, instead of gdi+

. optimize repainting. I have 2 ideas.

1. Per-control bitmap cache. A flag on Control that requests using a
cache bitmap. If a given control is complicated to draw, we wouldn't
have to draw it every time during MuiPainter::Paint() but simply blit
if that control hasn't changed. Simple to implement but of limited use. 

2. Layers. We could add capability to group controls into z-ordered
layers. Each layer would have a cache bitmap. We would only need to
redraw a given layer if some control in has changed. This would allow
dividing controls into those that change frequently and those that
don't change frequently and putting them on separate layer. An especially
important use case for this are animated controls like e.g. circular
progress indicator (placing them on a separate layer would probably
significantly reduce time to redraw the whole window).

. since we already paint to a cached bitmap, we could do rendering
on a background thread and then just blit the bitmap to a window in
WM_PAINT, assuming rendering on a non-ui thread is ok with gdi+.
Technicall in WM_PAINT we could just start a thread to do the painting
and when it's finished we would bilt the bitmap on ui thread. If there
were WM_PAINT messages sent in-between, we would note that and start
painting again when the in-progress painting has finished.

. optimize size of Control. One idea is that instead of embedding rarely used
properties (like e.g. Control::hwndParent), we could maintain separate mapping
from Control * to such properties e.g. in an array. Another idea is to move
rarely used fields into a separate struct linked from Control. If none of rarely
used fields was set, we wouldn't have to allocate that struct.

. could switch to layout units like in https://trac.webkit.org/wiki/LayoutUnit,
https://wiki.mozilla.org/Mozilla2:Units, https://bugzilla.mozilla.org/show_bug.cgi?id=177805

. not sure if HwndWrapper should be Control

