Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete back-end integration with OS #139

Open
aseprite-bot opened this issue Aug 20, 2014 · 13 comments
Open

Complete back-end integration with OS #139

aseprite-bot opened this issue Aug 20, 2014 · 13 comments

Comments

@aseprite-bot
Copy link

@aseprite-bot aseprite-bot commented Aug 20, 2014

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 laf-os. It's necessary to port the entire program to other backend (from Allegro 4 to Allegro 5, SDL2, SFML, Cinder, Skia) 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


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)
  • Remove Allegro back-end
  • Tablet pen support on X11 (eraser tip, etc.)
  • Update widgets layout in real-time when resizing window (#2536)
  • Update ui library to support multiple ui::Manager/os::Displays
  • Add cross-platform IME support
@dacap
Copy link
Member

@dacap dacap commented Mar 16, 2015

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

@dacap
Copy link
Member

@dacap 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
Copy link
Member

@dacap 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
@tony
Copy link
Contributor

@tony 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.

@dacap
Copy link
Member

@dacap 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.

@tony
Copy link
Contributor

@tony 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.

@dacap dacap modified the milestones: v1.2, v1.3 Sep 12, 2017
dacap added a commit that referenced this issue Aug 9, 2018
dacap added a commit that referenced this issue Aug 23, 2018
@dacap dacap pinned this issue Feb 24, 2019
@dacap dacap changed the title Add a new abstraction layer to port the entire application to other back-ends Complete back-end integration with OS Mar 5, 2019
@warmwaffles
Copy link

@warmwaffles warmwaffles commented Jul 3, 2019

@dacap is the skia dependency hard locked into the forked and branched version? I'm trying to compile this cleanly on archlinux with the AUR and it's proving to be quite the challenge. If it is locked in to that forked version and branch, that is fine by me. Just need to do some tweaking here.

@cosmicchipsocket
Copy link

@cosmicchipsocket cosmicchipsocket commented Aug 2, 2019

@dacap Also an Arch Linux user. Did a system update so I had to rebuild aseprite. Got latest "aseprite" AUR package and it didn't build. Tried "aseprite-git" and it also fails to build. Went to try and install it through the itch.io client (as that's where I purchased aseprite) and it can't install because the packages are .deb files instead of .tars (presumably the Steam version is cross-distro, but I'm not buying again just for that).

This change seems to have been made without any input from Linux users. If it were me I would have chosen SDL2 but I don't have a say in this. I guess now because I can't compile due to Skia, I have to manually take apart the .deb file and hand-install it? Or wait another month or so for the PKGBUILD to be fixed?

I was in the middle of some artwork but now I'm thinking I may be SOL!

@theParadox42
Copy link

@theParadox42 theParadox42 commented Apr 15, 2020

Is there still a future where this lands on iOS?

@dacap
Copy link
Member

@dacap dacap commented Apr 15, 2020

Yes, we have an iOS port, but it's not ready and it's not usable.

dacap added a commit to aseprite/laf that referenced this issue Apr 24, 2020
dacap added a commit that referenced this issue Apr 24, 2020
- Added support to detect eraser tip on Linux (#610)
- Related to #139
- Still needs works for gradients and better brush interpolations
  between stroke points
- Requested several times, e.g. https://community.aseprite.org/t/1077
  https://community.aseprite.org/t/1881, steam forum, etc.
zaghaghi added a commit to zaghaghi/aseprite that referenced this issue Apr 30, 2020
- Added support to detect eraser tip on Linux (aseprite#610)
- Related to aseprite#139
- Still needs works for gradients and better brush interpolations
  between stroke points
- Requested several times, e.g. https://community.aseprite.org/t/1077
  https://community.aseprite.org/t/1881, steam forum, etc.
@isametry
Copy link

@isametry isametry commented Jul 24, 2020

Yes, we have an iOS port, but it's not ready and it's not usable.

What kind of "not usable" are we talking here, if i may ask? in terms of controls, i think it could be hooked up to UIKey and UIPointer quite easily.

I would love an .ipa to just mess around with, i really hope that alfa/beta testing will soon be available for the iOS version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants