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

Undo notifications rendering problems #297

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

Undo notifications rendering problems #297

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

Comments

@aseprite-bot
Copy link
Collaborator

From DocHoncho@gmail.com on November 27, 2013 01:53:52

What steps will reproduce the problem? 1. Execute any two operations, especially where the second one has a longer undo message than the first (E.g., Draw with pencil, then flip horizontally)
2. Undo both operations What is the expected output? What do you see instead? Undo notification looks like it is being drawn into an uncleared Bitmap/Memory Region. Seems to affect any undo message that is shorter than the previous one, and has been done in rapid succession.

The time factor is especially interesting.

(Note that the image is modified, the bottom notification is a real example of a corrupted message, the one on top is added for comparison) Please use labels and text to provide additional information.

Attachment: Undo Message Glitch.png

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

@aseprite-bot aseprite-bot added this to the v1.0 milestone Aug 20, 2014
@aseprite-bot
Copy link
Collaborator Author

From davidcapello on November 28, 2013 08:42:28

This is a known issue. Anyway it's good to have it here in the tracker.

To fix this problem we need alpha support for ui::Window (compositable windows). It means: a flag that says "this window should be painted with a special background, that special background is all the widgets overlapped by the window", so a double-buffered technique is need in that case.

The main problem: we cannot do this until all widgets use onPaint() event. There are widgets that draw directly on ji_screen/Allegro screen when they receive a kPaint message, so we cannot draw those widget in the "temporary background" yet.

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on January 05, 2014 18:18:28

Labels: Version-0.9.6-beta1

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on February 02, 2014 20:06:37

Labels: -Version-0.9.6-beta1 Version-0.9.6-beta2

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on February 24, 2014 03:16:57

Labels: -Priority-Medium Priority-Low

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on February 24, 2014 05:10:28

Labels: -Version-0.9.6-beta2 Version-0.9.6-beta3

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on March 08, 2014 16:39:17

Owner: ---

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on April 09, 2014 18:42:15

Labels: Milestone-1.1

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on April 19, 2014 14:52:37

Fixed. Commits: af4e714 a34d181

Status: Fixed
Owner: davidcapello
Labels: -Milestone-1.1 Milestone-1.0

@aseprite-bot
Copy link
Collaborator Author

From davidcapello on July 16, 2014 18:02:54

Labels: -UI-SpriteEditor Component-UI-SpriteEditor

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

1 participant