Skia Rework

[flabbet]

Should work faster than forest fire. This is a preparation for direct bitmap rework

PixiEditor used to do all image processing using WriteableBitmap/WriteableBitmapEx. That approach proved to have multiple problems such as:

• All drawing is done on the cpu which is too slow.
• WriteableBitmapEx requires WriteableBitmaps with premultiplied alpha. Alpha premultiplication effectively limits color resolution for translucent pixels.
• WriteableBitmap being a part of WPF is not cross platform.
• Advanced features like layer masks or blending modes require hardware acceleration and can't be feasibly implemented with WriteableBitmaps.

This PR changes the entirety of PixiEditor to use SkiaSharp library for drawing. It also changes all tools to work with the bitmaps directly using SkiaSharp drawing functions wherever possible. Apart from that there are some minor changes, mainly the optimization of fill algorithm.

[codecov-commenter]

Codecov Report

Merging #211 (8cecdf1) into master (436c59d) will decrease coverage by 44.75%.
The diff coverage is 0.00%.

❗ Current head 8cecdf1 differs from pull request most recent head a6d0ba5. Consider uploading reports for the commit a6d0ba5 to get more accurate results

@@            Coverage Diff             @@
##           master    #211       +/-   ##
==========================================
- Coverage   44.79%   0.04%   -44.76%     
==========================================
  Files         301     305        +4     
  Lines       12199   12164       -35     
  Branches     1205    1226       +21     
==========================================
- Hits         5465       5     -5460     
- Misses       6463   12159     +5696     
+ Partials      271       0      -271     

Impacted Files	Coverage Δ
...iEditor/Helpers/Converters/BoolToBrushConverter.cs	0.00% <ø> (ø)
...ixiEditor/Helpers/Converters/BoolToIntConverter.cs	0.00% <ø> (ø)
PixiEditor/Helpers/Converters/BrushTuple.cs	0.00% <0.00%> (ø)
...iEditor/Helpers/Converters/DoubleToIntConverter.cs	0.00% <0.00%> (-55.56%)	⬇️
...ers/Converters/EmptyStringToVisibilityConverter.cs	0.00% <0.00%> (ø)
...rs/Converters/EqualityBoolToVisibilityConverter.cs	0.00% <ø> (ø)
...elpers/Converters/FileExtensionToColorConverter.cs	0.00% <0.00%> (ø)
...s/Converters/FinalIsVisibleToVisiblityConverter.cs	0.00% <0.00%> (ø)
PixiEditor/Helpers/Converters/FloorConverter.cs	0.00% <ø> (ø)
...itor/Helpers/Converters/FormattedColorConverter.cs	0.00% <0.00%> (ø)
... and 215 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 436c59d...a6d0ba5. Read the comment docs.

[Equbuxu]

Make a 512x512 canvas, draw a line diagonally going from top left to bottom right (the line should separate the canvas in two). Using the fill tool, double click on one of the halves. Wait for it to process and then move your mouse to the second half. The second half gets filled too because the mouse button got stuck (doesn't happen all the time, try again if it didn't).

I did some not-so-scientific testing to find out that the new algorithm is about 6.5 times faster than the previous one. (474 ms vs 72 ms on the image I tested). Howerer, the previous algorithm used to run in 0 ms in cases where you are trying to fill the area with it's same color (e.g. fill a white area with white). The new algorithm takes about the same time in this case (72 ms). The fill tool gets used at least twice every time you click, and way more than twice if you click and drag. Because of that the new algorithm can actually be slower, as the previous one only ran for a long time once while the new one takes the same time to run many times in a row.

TLDR: make it so fill tool is only called once per click and/or don't fill the area if it's color matches the fill color.