with some transparency

We spoke about having tests to ease refactoring and robustness.

Another complementary and cheaper approach could be to have jsdoc tags combined with a closure compiler validation pass. It will give us a kind of type validation and it's a time-saver to smoke test big refactor.

Note that I don't really care about compressing the code size, I just want to use the compiler validation.

What do you think?

So we need some tests.
Ideally, we need:

• CI integration smoke tests (high level (eg: is the page loading and building markup?), not too much and plugged on TravisCI)
• component level testing (mid level (eg: drawing canvas, tools), a lot of them and should run at code time if fast enough)
• unit testing for low level and easy pieces (low level, a lot and should run at code time)

How do we mark private JavaScript function?

I saw some prefix or suffix underscore in our current code base. We could as well use the private jsdoc tag?
I'm used to suffixing and and adding a private but I don't have any preferences.

Tested on Firefox Nightly (24.0a1), the right hand side drawer is not positioned correctly.

The display: table property here
https://github.com/juliandescottes/piskel/blob/master/css/style.css#L58
seems to be the reason for it.

Cheers

So I propose this new interaction to allow quick access to previously used colors and tools.
This interaction is based on the right click in two different modes:

• short right click: Select previously tool/color
• hold right click: Trigger the 'previously used tools/colors' wheel

Spec for the 'previously used tools/color' wheel:

• look at secret fo mana whel of items/magic: http://lpix.org/509110/SD3%205_3.png
• the wheel appeat centered on the right click location
• the wheel is a circular distribution of previously used items
• in the middle of the circle, you show the currently selected tool (before the right click)
• in the top part of the circle, you show X previously used tools
• in the bottom part of the circle, you show the last Y used colors
• when circle is open and when you hover a tool or color, the item in the middle of the circle gets updated.
• when you release the right click, the item in the middle is selected.

That's an initial implementation proposal to see how it flies. Lot of stuff can be changed depending on UX feedback, eg:

• You can imagine that the right click act as toggle (instead of having to hold it and release on the tool you select)
• number of displayed tools and palette have to be fine-tuned (even allow user customization?)
• a small circular and really light transparent background below wheel's tools may help to differentiate them from your canvas in the background.
• you can remove that if people do prefer 5 keystrokes shortcuts

Thought, strong feelings against that?

Transformations:

• rotations
• scaling/resizing ?
• flip horizontally/vertically

For now, we don't support partial opacity for colors. We either show 100% opacity colored or totally transparent pixels.

Do we want to support opacity pixels in the future?

May lead to a bunch of problems/new challenges:

• GIF format does not support semi transparency, we may need to move to/dual-support animated png
• How do you manage overlapping layers of semi-transparent colors? mixed, overlay, discard the first one ?
• how do you manage a future canvas color picker?
• increased complexity (one addtional param to manage a fill color)

Evident benefits are:

• more POWA!
• antialiasing

For now, I'm good not supporting that but I'm curious of your point of view, pros and cons on this one.

On a new piskel :

http://juliandescottes.github.com/piskel/?size=24x24

it works fine but on an already created one :

http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEgsSCkZyYW1lc2hlZXQYo5kCDA

The tool doesn't work.

Raised during PR #109

Which browsers do we aim to support ?

• Latest Chrome and Firefox for sure.
• IE ??
• Safari ??
• Opera ??
• Omniweb ?? (trololo)

Let's keep the discussion around desktop browsers, since piskel is not mobile/tablet ready.
My take :

• IE 10 + : why not, if not too costly. IE still lags behind when it comes to standards and it also lacks the auto updates
• Safari : would actually be nice since it paves the way to support safari mobile. But that's the only reason I see.
• Opera : I don't care

Do we test all of them ? Or do we just try not to break the browser compatibility voluntarily (and fix bugs when reported)

(OK I did too much GAE and want to puke but ...)
I found that:
https://github.com/h5bp/mothereffinganimatedgif
https://github.com/antimatter15/jsgif

Not really perfect but we could probably improve it (currently no support for multiple colors/palette and the trasnparency looks really bad)?

Using the Canvas toDataURL API :

var canvas = document.getElementById("mycanvas");
var img    = canvas.toDataURL("image/png");

Concatenate all frames in a single sequence of images and export/save as a single PNG file.

Animations are 32*32 only. This obviously needs to be configurable.

Would be nice to see somewhere the position of the cursor in terms of "frame" pixels.

Cursor at : 10x05

Also when using tools such as rectangle/circle/selection, could be good to have contextual information about the area being selected.

When using tools like pen or eraser, could be nice to slightly highlight the target pixel that may be affected. It should be really subtle (like opacity 90% for a real color or white/opacity 10% for a transparent target pixel).

It might be cool and also useful to edit a single frame by computing several layers

Do something that resembles more paint, paint.net etc ... Users need to quickly understand that this is about primary/secondary color selection.

Need to be able to edit several frames at the same time.

I really like the new icons, but I would prefer if the tools were in their zone of 'action' :

• add button should be in the left panel (save button could be somewhere else)
• tools should near the drawing canvas
• fps slider should be near the animated preview

For now stroke thickness is hardcoded to 1px.
Bring ability to make it bigger (for any tool: stroke, pen, rect, circle, etc).

On Chrome Version 22.0.1229.26 beta-m .

When hovering on tools, there are MAJOR slowdowns on this version of chrome. It seems to be linked to the display of the 'title' attribute.

Removing the title attribute fixes the issue but maybe we should first refactor the redraw loop.

Go to http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEgsSCkZyYW1lc2hlZXQY6YQBDA

The frame selected by default is not displayed inside the drawing canvas.

Our first official backend bug. awesome...

I just did an animated sprite and I'm getting 500 from gae when trying to save it. The sprite is pretty big (a lots of frame) and the serialized framesheet is around 1.1mb.

I can't see any 500 log from GAE console and I know there is a 1MB limit on GAE.

I saw this as well (non scalable workaround using zlib compression):
http://atastypixel.com/blog/breaking-the-limits-storing-data-bigger-than-1-mb-in-google-app-engines-datastore/
or scalable technics:
http://stackoverflow.com/questions/5081502/memcache-1-mb-limit-in-google-app-engine

Have a look at : http://www.humanbalance.net/gale/us/spec.html

Basically this feature displays the previous and next frame on the drawing canvas, in semi transparent mode. Looks awesome for animating characters !

Transformations:

• rotations
• scaling/resizing ?
• flip horizontally/vertically

When copying a savedState to the frame, the reference is passed. If the frame is edited, the state gets modified.

Dirty fix for this is to reuse the _clonePixels method on the Frame as follows :

ns.Frame.prototype.loadPreviousState = function () {
    if (this.stateIndex > 0) {
        this.stateIndex--;
        this.pixels = this.previousStates[this.stateIndex];
        this.pixels = this._clonePixels();
        console.log(this.stateIndex);
    }
};

But I'll try to spend some more time on it this evening to find a proper solution.

Again inspired by what all image edition tools do

DPI is changed, but drawing controller won't redraw until the next frame/overlay change.

Need to force redraw for DrawingController in case of DrawingConfiguration change

When activated, whatever you do on the one side is reimpacted on the other one. It makes only sense for subset of tools (simplepen, eraser, eventually stroke)

Before the palette was initialized with all the colors used in the animation.
Doesn't work anymore (example : http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEQsSCkZyYW1lc2hlZXQY4V0M)

Ability to create and label palettes that could be used across different framesheets (skin colors, glass/wood colors etc).
They have to be persisted independently from a given framesheet model.

:(

Either that or a multi-edit batch mode. But I think a selection tool with copy/paste/move will come in handy

When loading an animation with speed != from 12FPS, the speed is correct, but the slider always initialized at 12FPS.

See http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEgsSCkZyYW1lc2hlZXQYme8CDA

Would be nice to have this, to automatically see the latest version of the app running, without having to redeploy manually.

Maybe should be deployed in a subfolder (/latest) to avoid automatically overriding the "stable" version.

Regression in Chrome cursor handling: https://code.google.com/p/chromium/issues/detail?id=172857.

The rendering is heavy : need to explicitely call the controller responsible for a given area of the layout, and ask it to redraw its components. And there is no common redraw or render method : for each controller you have to call different methods.

The goal of this task is to make the rendering process automatic.

A drawing loop based on request animation frame will run in the background, and will call the different controllers. The controllers will be responsible for checking the models they are relying upon and will choose the most appropriate way to redraw their UI components.

Try selection tools at http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEgsSCkZyYW1lc2hlZXQY6f4CDA

The selectionManager is caching low level objects (frames).
When the application loads an existing piskel, we first set a picture size of 32x32 and then change the size when we receive the info.

However the Selection Manager is directly using (and caching) framesheet objects. Therefore it's not compatible with this use case.

• option 1 : make Selection Manager use proper APIs
• option 2 : differ initialisation of controllers/managers until necessary data is available.

Load http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEgsSCkZyYW1lc2hlZXQY8agCDA (16x16), using the pen tool you can see the "hover" effect displayed outside of the drawing canvas.

If you inspect the DOM you can see the overlay canvas is twice the size of the drawing canvas.

Zoom level is for now hardcoded to 20 in piskel.js

User should be able to dynamically change this.

Looks like transparent color created by the ERASER tool is not identical to the default transparent color (the one you get with an empty frame for instance).

Try to use the paint bucket inside the PINK zone here : http://juliandescottes.github.com/piskel/?frameId=agxzfnBpc2tlbC1hcHByEgsSCkZyYW1lc2hlZXQY6YQBDA . The bucket doesn't expand as expected :)

:(

From @captainbrosset :

What about a bigger, more obvious, color palette, very close the the canvas, where simply hovering over one of the colors would assign it to the current tool? Would make the need for a secondary color less important and would bring a very fast and smooth (no freaking click or cumbersome keystroke in the way) way of switching color, which is, I guess, is what you end up doing most often.

Similar to rectangle tool, but for circles.

I need to draw bubbles !