Migrate code from aseprite to laf

[dacap]

My plans for the UI part of the laf library are:

• Move the she library from aseprite to laf::os namespace.
• Move the ui library from aseprite to laf::ui namespace.
• Refactor events (mainly keyboard events) to be more DOM spec-like [1], [2], [3], [4], [5].

[YumaTheCompanion]

Any update on this one; "Move the ui library from aseprite to laf::ui namespace." ?

I'm currently using SDL with Skia, but considering using LAF. As far as I can see, it needs the ui modules and perhaps some more. Am I correct?

[dacap]

Hi @YumaTheCompanion, the ui library from Aseprite needs the obs library too.

Anyway there are no short-term plans to move the ui library to laf because I have plans to change the API a little (the ui library has some inconsistencies between classes, mainly comboboxes vs listboxes). Even more, not sure if the library will be part of the laf library sometime in the future (it's too customized for Aseprite usage only).

[dacap]

Other thing I forgot to mention, is that the laf-os API is unstable too. I have plans to expose more Skia stuff in the future (anyway it should not change too drastically I guess).

[YumaTheCompanion]

Hi @dacap , I checked (actually read the library from top to bottom) the LAF library and yes there are some things that needs to be done, true. However, as a starting point, maybe we can add simple functionality? By that I mean this: normally, I use SDL and GPU render the skia surface into SDL window. However, as far as I can see, LAF uses native Cocoa to create the window. Am I right? So basically, if you can create a simple and functionaly LAF library that just generates native window handles (Windows, *nix, MacOS) and passes them to Skia with GPU rendering, a lot of people would be able to experiment and even contribute.

[YumaTheCompanion]

So as of now, just a basic window handle is more than enough for most people. I generally develop on a mac, and I'd much prefer cocoa+metal window rather than an SDL+opengl window (OpenGL is deprecated with OSX 10.14).
If you can provide such a library, perhaps I can be of more help (not that you need).

[dacap]

There are some progress for the GPU renderer (search for SK_SUPPORT_GPU), and at least I do have plans to provide what you said 👍

I'll start creating some examples in the project so we can start finally adding/fixing the GPU support. Then, it would be great to expose more of the Skia API (or a way to expose the Skia API directly, anyway I'm not a big fan of this, because the Skia API changes from time to time too).

[YumaTheCompanion]

Ah great, I think GPU support is a good place to start finishing. Some examples would be nice, as you said.

And yes, Skia API has changed over time, even the official website of theirs have deprecated api. Perhaps we can come up with some sort of a wrapper?

Let me know if there is anything I can help.

[dacap]

The first step I'll make is creating a simple example, for this I want to remove pixman, freetype, and harfbuzz as direct dependencies (and use all the Skia API for drawing text).

The idea is to create a Skia wrapper little by little (some examples of wrappers are os::ColorSpace or os::Surface:: drawSurfaceNine()).

[YumaTheCompanion]

A simple example, as you mentioned, could be nice. For example, you could make a working version of the sample code about text manipulation, residing in skia/samplecode. Most of them requires adjustment, as of now.

We definitely need to create a Skia wrapper. Because, almost none of the sample code on Skia library works out-of-the-box. All has either deprecated API or some weird data structure.

I haven't checked much, but "Chromium" has some rather up to date Skia usage. Maybe that'll help?

I'm working on a project, it's basically a lightweight cross-platform, cross-language IDE. The current options are: use wxWidgets or Qt (too restrictive or large), or use Skia (too much DIY). I think there is an opportunity there, to give rise to a new open-source UI framework, that resides in the middle of both parties. I bet a lot of people could be interested in developing it as OSS, if the right steps are taken.

[dacap]

I'm preparing a basic "helloworld" example as a first step so I can get rid some dependencies (so maybe we can depend on Skia only, and not on freetype/harfbuzz/pixman) and improve the compilation of the library alone.

I've no plans to provide a full Skia wrapper on laf at the moment but that might be another project (?). My plans are to expand the laf API while a new use case appears (like an evolving API, instead of providing all the stuff that Skia provides).

[dacap]

I've created a project to keep track of the progress: https://github.com/aseprite/laf/projects/1

[dacap]

I've pushed some code in the refactors branch.

[YumaTheCompanion]

I've no plans to provide a full Skia wrapper on laf at the moment but that might be another project (?). My plans are to expand the laf API while a new use case appears (like an evolving API, instead of providing all the stuff that Skia provides).

Evolving API sounds good, as providing a full wrapper would be cumbersome and kind of hard to direct.

I'm preparing a basic "helloworld" example as a first step so I can get rid some dependencies (so maybe we can depend on Skia only, and not on freetype/harfbuzz/pixman) and improve the compilation of the library alone.

Yes, that'll be most perfect.

[YumaTheCompanion]

I've created a project to keep track of the progress: https://github.com/aseprite/laf/projects/1

Nice. If I can, ill test on my mac 10.14 mojave and report issues if any.

For one thing, on my system, I had to compile with bin/gn gen out/Release2 --ide=xcode --args="is_official_build=false is_debug=true skia_use_system_expat=false skia_use_system_icu=false skia_use_system_libpng=false skia_use_system_zlib=false skia_use_libwebp=false skia_use_system_harfbuzz=false extra_cflags_cc=[\"-frtti\"]"; ninja -C out/Release2;.

This is because I cant somehow use Skia with my Xcode on my custom project without the debug symbols. Anyway, if you can put up the "HelloWorld" example, I'll immediately try it with your official Skia branch and build instructions and report back.

[dacap]

This is because I cant somehow use Skia with my Xcode on my custom project without the debug symbols.

👍 Yeah, no problem, actually we should be able to use different Skia compilations (and try to support as many different compilation switches as possible)

if you can put up the "HelloWorld" example, I'll immediately try it with your official Skia branch and build instructions and report back.

A simple helloworld example is already published in the refactors branch. Check it out and see if it does work 👍(I've compiled it on macOS and Windows). (It doesn't support OpenGL yet.)

[YumaTheCompanion]

I've checked the HelloWorld example. Here are my results:

Step 1) git clone https://github.com/aseprite/laf.git --recursive
Step 2) Applied the official instructions:

First, it did not compile, complaining that SKIA_SKCMS_INCLUDE_DIR was not defined. Based on your source code here: https://github.com/aseprite/laf/blob/master/os/CMakeLists.txt, I figured I had to use /skia/third_parth/skcms path and add the path variable as a cmake flag. So my final cmake build command was:

cmake -G Ninja -DSKIA_DIR=/Users/yuma/skia -DSKIA_OUT_DIR=/Users/yuma/skia/out/Release2 -DSKIA_SKCMS_INCLUDE_DIR=/Users/yuma/skia/third_party/skcms ..

This generates cmake files successfuly.

Step 3) Used ninja command to build, (I tried different out/XXX) files but the result is the same:

An warning at 67/128
[67/128] Linking CXX static library base/liblaf-base.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: base/liblaf-base.a(debug.cpp.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: base/liblaf-base.a(debug.cpp.o) has no symbols

After a couple more warnings:
/Users/yuma/skia/include/core/SkColorSpace.h:11:10: fatal error: 'include/core/SkMatrix44.h' file not found #include "include/core/SkMatrix44.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.

But, the file is there on the filesystem.

What can be the problem?

[dacap]

🤔 Just in case check your CMakeCache.txt file in your build directory and see if all paths are set, e.g.:

//Path to a file.
SKIA_ANGLE_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/third_party/externals/angle2/include

//Path to a file.
SKIA_CODEC_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/include/codec

//Path to a file.
SKIA_CONFIG_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/include/config

//Path to a file.
SKIA_CORE_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/include/core

//Skia source code directory
SKIA_DIR:PATH=/Users/david/repos/skia-m71

//Path to a file.
SKIA_EFFECTS_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/include/effects

//Path to a file.
SKIA_GPU2_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/src/gpu

//Path to a file.
SKIA_GPU_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/include/gpu

//Path to a library.
SKIA_LIBRARY:FILEPATH=/Users/david/repos/skia-m71/out/Release/libskia.a

//Path to a library.
SKIA_OPENGL_LIBRARY:FILEPATH=/System/Library/Frameworks/opengl.framework

//Skia output directory
SKIA_OUT_DIR:PATH=/Users/david/repos/skia-m71/out/Release

//Path to a file.
SKIA_SKCMS_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/third_party/skcms

//Path to a file.
SKIA_UTILS_INCLUDE_DIR:PATH=/Users/david/repos/skia-m71/include/utils

[dacap]

Did you check out the branch aseprite-m71 of Skia?

[YumaTheCompanion]

No, I was using the official one. Let me try m71 branch of yours.

Also, I've checked the CMakeCache.txt file, everything seems okay.

[YumaTheCompanion]

Okay, downloaded and built m71 branch as instructed on your page. It builds successfully, without errors.

After that, tried to compile LAF with the following cmake flags:

cmake -G Ninja -DSKIA_DIR=/Users/okanb/repos/skia -DSKIA_OUT_DIR=/Users/okanb/repos/skia/out/Release -DSKIA_SKCMS_INCLUDE_DIR=/Users/okanb/repos/skia/third_party/skcms -DLAF_WITH_TESTS=OFF ..

I needed to turn off tests because of some library error :
Undefined symbols for architecture x86_64: "is_orientation_marker(unsigned char const*, unsigned long, SkEncodedOrigin*)", referenced from: SkWebpCodec::MakeFromStream(std::__1::unique_ptr<SkStream, std::__1::default_delete<SkStream> >, SkCodec::Result*) in libskia.a(webp.SkWebpCodec.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed.

Anyway, with that, I compile with this return value:
[63/72] Linking CXX static library base/liblaf-base.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: base/liblaf-base.a(debug.cpp.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: base/liblaf-base.a(debug.cpp.o) has no symbols [72/72] Linking CXX static library os/liblaf-os.a

I assume this is a successful compile? I'm asking because there is no "helloworld" example and no "example" folder.

What could be wrong?

[YumaTheCompanion]

Ah okay, I was working on master branch, not refactor branch.

There's still a compile error though, probably some dependency is missing. I'll try to figure it out and get back to you. 👍