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

Closed
8 of 9 tasks
aseprite-bot opened this issue Aug 20, 2014 · 14 comments
Closed
8 of 9 tasks

Complete back-end integration with OS #139

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

Comments

@aseprite-bot
Copy link
Collaborator

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 (Window resizes by scaling #2536)
  • Update ui library to support multiple ui::Manager/os::Displays
  • Add cross-platform IME support #2841
@dacap
Copy link
Member

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 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 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

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

@KeyboardDanni
Copy link

KeyboardDanni 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

Is there still a future where this lands on iOS?

@dacap
Copy link
Member

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 pushed 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

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.

@dacap
Copy link
Member

dacap commented Jul 16, 2021

I'm closing this issue as the laf-os layer is already done in its most part, and every new feature (e..g IME support) will be specified in other issues.

@dacap dacap closed this as completed Jul 16, 2021
@dacap dacap unpinned this issue Jul 16, 2021
dacap added a commit that referenced this issue Aug 24, 2021
Each ui::Window now can have a related native os::Window. This
connection is done through the ui::Display class added recently in
c3d52f0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants