Target is to implement all blending modes that PhotoShop and GIMP support today. A code generator should be written for the software fallback to avoid code duplication.

The Picture class is largely uncovered. Some other parts could use more fine-grained testing as well.

Some events don't affect the state of the buffer's bitmap and don't require playback if they change. Take this into account in all situations.

Out-of-sequence undo for move events doesn't produce very good results yet.

One reasonable goal for out-of-sequence undo would be that the following sequence would not change the picture:

1. Move event A
2. Move event B
3. Undo move event A
4. Undo move event B

but it's a bit unclear what's the best way to do this. Merges happening between move & undo can also mess things up, that should be thought about.

This becomes necessary to manage GPU memory usage as the layer count and/or size of the picture increases. So it's readPixels time!

Is there a preferred way to clear the current Picture instead of destroying it and recreating with a new Picture and then appending it to the drawArea?

Thank you

The color space of the picture color values should be defined.

There could be options for blending in linear or perceptual space.

-Implement freeing memory entirely for buffers whose creation has been undone (for applications that don't use redo)

-Implement a method for choosing the least useful undo state from a buffer. This can be used to stay within budget as new undo states are added, as well as reducing the budget. For this, approximating the regeneration cost of an undo state could be done by calculating undoState.index - previousUndoState.index. Combining this somehow with the likelihood of it being used should provide a decent metric for which undo states to get rid of (or move to CPU memory as an intermediate step).

-Implement global memory budgets and a policy to select the least-relevant buffer to reduce their budget. Could be based on a least-recently-used policy.

Adding a script for compiling the unit tests along with the code would be the most obvious idea. The unit tests integrate with the code so tightly, that only compiling the code and exporting everything that's necessary for the tests is not really feasible. The big unknown here is how to handle the interface with Jasmine.

The circle in brush strokes should be possible to replace with an arbitrary bitmap. As an option, the picture could be rotated for each blit according to the brush direction.

WebGL multitexturing-based layer compositor is subject to texture unit limitations. Make it scale beyond the amount of texture units provided. WebGL/Canvas 2D compositing could also be abstracted away from the Picture class.

First I must say this is by far the best open source JS brush engine I've seen. Thanks for sharing it.

I'm trying to set the BrushTipMover spacing and scatteroffset attributes. So far I created a brushevent using createBrushEvent, but then it seems I have to assign a value to PictureEvent > BrushTipMovers > ScatterOffset in a mouse move event?

this.currentEvent.BrushTipMovers.ScatterOffset = "10" 

The functions available on BrushTipMover don't seem to have any setters. Is this the right way to adjust that setting?

Thanks!

This would improve robustness of the code. Asserts offered by the Google library would probably be the best choice, since the library is already written with Closure compiler in mind.

Currently the pressure parameter alters the radius of the brush stroke. It would be beneficial if the pressure could also be used for changing the opacity and flow settings. The Photoshop brush allows the user to choose which brush properties are changed with pen pressure.

This type of vertex shader code failed to render a vertical gradient, which is why the current code generates different shaders for vertical and non-vertical gradients:

if (abs(uCoords0.x - uCoords1.x) < 0.001) {
varying = vertical gradient formula;
} else {
gradient code
varying = result;
}

Figure out if this really was a bug in WebGL / NVIDIA driver v311 stack or some misunderstanding, and see if it reproes elsewhere.

This could be faster since texSubImage2D doesn't need to do as much error checking. Alternatively could try using uniform arrays.

The blending shaders should implement at least one of these two modes:

1. If blending mode is other than normal and target pixel opacity is 0, draw with normal mode (equivalent to PhotoShop).
2. Option to keep target pixel opacity when drawing, which would be always on when blending mode is other than normal.

This will replace the current behavior, where blending to target of 0 opacity with other modes than normal hasn't been addressed as a special case, and the result is what happens to come out of the formula. Existing pictures breaking because of the changes is acceptable.

This will involve at least making sure GLSL uniform names are referenced only in strings, not in property names with dot notation. Otherwise uniform names will be inconsistent between JS and GLSL when they're shortened in JS.

It should be possible to merge two buffers into one, rendering their compositing result to the bottom buffer. The merge should be added as an event to the bottom buffer, and be undoable like other events.

Operations that are not currently handled by events:
-Add a buffer
-Remove a buffer
-Move a buffer in the stack
-Change buffer settings (opacity, visibility, eventually mode...)

These could either be stored in an events array in the Picture itself, or in the buffer they relate to. If the latter approach is chosen, an addBuffer event would then always be the first thing stored in any buffer.

I have an array of object literals for image brush textures. I loop to create img elements that are then pushed into a brushTextures array. That array is passed into the renderer when a picture is initialized. It appears as if they aren't loaded by the time Picture is attached, and brush events are pushed to the picture. This throws a bunch of web gl 'no image' errors in the console.

They eventually load when I go back to my page but the first time, there is no brush output if i'm using a textureid on the brush event.

Can we add a way in the renderer to keep loading the textures even after Picture has been attached to the canvas?

Events like EventHideEvent and BufferRemoveEvent aren't really the same thing as the events that make up PictureBuffer contents. Consider storing them in a different array inside PictureBuffers. This might make managing PictureBuffer contents a bit simpler.

Write a test that verifies whether varyings get interpolated at the pixel center (0.5, 0.5) and if not, think about possible ways to compensate for misalignment. Gradient rendering code could be used for this.

This would be useful for multitouch applications. Basically, the currentEvent could be replaced with an array of events, and Picture.setCurrentEvents() added beside Picture.setCurrentEvent(). A multitouch example could be built on top of this.

The library should be able to determine when undoing a buffer removal becomes unlikely enough that the memory for the removed buffer can safely be freed. Freeing could also be done always if the buffer's contents are cheap to regenerate on undo.