Add a new abstraction layer to port the entire application to other back-ends #139

Open
aseprite-bot opened this Issue Aug 20, 2014 · 8 comments

Comments

Projects

Review in Touch devices

Maybe in Next release

3 participants

aseprite-bot commented Aug 20, 2014 edited by dacap

From davidcapello on July 16, 2012 00:45:55

The whole program should depend on a new layer that hide the details of Allegro 4 library. This library is she. It's necessary to port the entire program to other backend (from Allegro 4 to Allegro 5, SDL2, SFML, Cinder, etc.) The final objective is to support hardware acceleration in current platforms, and the possibility to port Aseprite to tablets (Android, iOS, Surface).

Original issue: http://code.google.com/p/aseprite/issues/detail?id=139

EDIT: Tasks:

  • Select an alternative library to handle graphics (Skia)
  • Windows and OS X Skia ports (officially released on v1.1.4)
  • Fix keyboard shortcuts with Unicode characters (mainly in 0009939)
  • X11 Skia port (for v1.2), with tablet pen support (eraser tip, etc.)
  • Remove Allegro back-end
  • Update ui library to support multiple ui::Manager/she::Displays

dacap added this to the v1.1 milestone Oct 17, 2014

dacap self-assigned this Oct 25, 2014

Owner

dacap commented Mar 16, 2015

The new backend will be implemented using Skia library, we've started some work in 0350ac4

@dacap dacap added low priority and removed medium priority labels Aug 5, 2015

@dacap dacap modified the milestone: v1.2, v1.1 Aug 28, 2015

This was referenced Aug 28, 2015

dacap removed the low priority label Oct 3, 2015

Owner

dacap commented Oct 3, 2015

We are in a kind of deadlock with Allegro 4:

  1. Allegro 4 needs OS X SDK 10.4 to be compiled correctly (because it uses QuickDraw)
  2. And we need a modern OS X SDK to provide touch events (and better integration with OS X)

On Windows there are still one odd crash report where a DirectDraw surface wasn't restored (probably fixed here), and on Linux we have lag problems with the mouse.

The solution we are working on is this:

  1. Use Skia for drawing primitives (and hardware acceleration if needed)
  2. Use direct API to handle Win32/OS X/X11 windows and events.

@dacap dacap modified the milestone: v1.1, v1.3 Apr 12, 2016

@dacap dacap modified the milestone: v1.2, v1.1 Jul 25, 2016

Contributor

tony commented Jun 27, 2017

Is this still being pursued? I ask because I think that since adding skia the build process has gotten a lot harder. It kind of made the on-ramp for me as a contributor harder:

  1. Skia isn't available as a library package on most systems
  2. I haven't tried building in a few months, but when I did skia didn't snap-in directly with a source build since it requires grabbing depot_tools and building on its own. Recently though, I see it has a "GN-to-Cmake" script, which I haven't tried yet.

SDL2, on the other hand, is already packaged as a library on most systems and pretty simple to find/build against with CMake. Here is the C++ wrapper I use with it: https://github.com/libSDL2pp/libSDL2pp

Owner

dacap commented Jun 28, 2017

Is this still being pursued?

Yes, I'm working on the Linux port but it's progressing slowly. The main issue with libraries like SDL2, Allegro, SFML, etc. is that they are focused on game programming, and not in application programming. And through all these years I reached to the conclusion that you need full control of mouse and keyboard messages (and all window messages in particular, e.g. to give proper support to pen/stylus).

The basic idea is that we should control all windows/keyboard/mouse messages from our side, and use Skia to draw on the screen (the same is done on chrome, all chrome-based apps, sublime text, etc.).

I ask because I think that since adding skia the build process has gotten a lot harder

Yes, I think exactly the same (and I have to compile Skia several times in several platform, and each time I have to update the Skia version is A LOT of work, even the API is unstable from version to version). Anyway, I think there is no other graphics library with so much effort to be improved as in Skia (Google has a lot of performance controls, metrics, etc.).

So at this moment, the idea is to continue using Skia, but I have plans (in a distant future) to replace it with our own rendering functions (based on each OS APIs).

Owner

dacap commented Jun 28, 2017

Another idea is to give support for several graphics libraries. E.g. we control all window/mouse/keys events, but we use several back-end libraries just to render graphics (e.g. SDL2, Allegro, SFML, etc.).

  • Pros: +give the chance to change the back-end on runtime +best performance on each platform +possibilities of compilation/run on more machines
  • Cons: -maintenance hell
Contributor

tony commented Jun 29, 2017

I wasn't around when the decision was made to use Skia. But what made it the choice over Allegro 5, SFML, and SDL2?

Another idea is to give support for several graphics libraries. E.g. we control all window/mouse/keys events, but we use several back-end libraries just to render graphics (e.g. SDL2, Allegro, SFML, etc.).

I've seen some examples of abstraction to allegro/sdl2/etc. in openttd: https://git.openttd.org/?p=branches/1.7.git;a=tree;f=src/video;h=14caa02f215d822ccb469d111f4c76c732866d92;hb=41937d6e6402fdbfedc926663a880d21deb603db (unfortunately the code itself is GPL'd).

Pros: +give the chance to change the back-end on runtime +best performance on each platform +possibilities of compilation/run on more machines

That would be interesting to see the results of.

Cons: -maintenance hell

I have nothing against skia other than it being a barrier of entry when building aseprite from source. As of this day, even Debian doesn't have a package for it, there's been an RFP request back in March 2016. Nothing in homebrew or freebsd ports at this time exists.

On the other hand, sfml, sdl2, and allegro are packaged across linux distros, homebrew and bsd ports, and could make the source easier to build from. Either one of them IMO would lower the barrier to contribute.

Owner

dacap commented Jun 29, 2017

But what made it the choice over Allegro 5, SFML, and SDL2?

I will quote a part of my previous message "through all these years I reached to the conclusion that you need full control of mouse and keyboard messages (and all window messages in particular, e.g. to give proper support to pen/stylus)."

So basically after seeing all the problems with Allegro 4 in these 17 years of development, I didn't want to make the same mistake again, so all the backend (she module) is programmed by us and for Aseprite specifically, and Skia is used only for graphics. This is the only way to have 100% control to fix issues with the keyboard, mouse, stylus, etc.

My future idea is that after removing Allegro 4 (which is used only on Linux at the moment), we'll be able to add new UI effects implemented through Skia.

Contributor

tony commented Jun 29, 2017

I understand the perspective better since the point on input/events was reiterated.

Originally, I was thinking maybe SDL2 would be an OK compromise since it's geared toward events/drawing primarily, it even has some code for handling stuff like stylus/touch (though I don't see support for stuff like tilt). I guess even SDL2 would be too high level since it manages the window and events.

I'm still stuck with skia making the project harder to build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment