Canvas suggestions

[Jordan]

Continuing the discussion started on the ML.
For more details the first message is here.

Here is a small summary that i believe representative of what was said:

Request for other operations than intersection for clipping path (like union, replace, substract and xor?). It seems it would be difficult to implement on some systems due to graphic API limitations, though.
At least, a way to reset the clipping path to the full canvas without having to call save() / restore() each time would be appreciated.

A better way to read colors. Return an array[4] instead of a string?
Actually the properties may fully behave like an array[4] if it is a color?
But setting to strings of format #xxxxxx and rgba(...) would still be allowed for backward compatibility?

Path API: a way to get the last point of the last subpath drawn and its orientation? Not absolutely needed, but shouldn't be too hard to implement, without breaking anything.

Transformations: Change the way transformations work to support the Firefox-ish / Safari-ish way? The way it is currently described in the spec is only implemented in Opera for now, and seems less versatile (and creates more overhead for implementations, it seems ).
(By the way, why was it choosen to be that way in the spec if it was already implemented by Apple the other way around? Is there a good reason? Does someone know?)
Also we DO need a way to get the CTM.

I think i have forgotten nothing important, except drawString(), but this deserves a topic on its own.
BTW, i didn't want to create too much topics to avoid proliferation, but maybe a small topic for each request would have been easier to keep track of? :-/

[vladimir]

Great suggestions! Some comments, at least from my point of view. I don't know how well this will work on the forums -- it would be good to get someone from Apple and Opera at least to chime in about their implementations, and I don't know if they're following the forums -- but we'll see.

Request for other operations than intersection for clipping path (like union, replace, substract and xor?). It seems it would be difficult to implement on some systems due to graphic API limitations, though.
At least, a way to reset the clipping path to the full canvas without having to call save() / restore() each time would be appreciated.

Resetting the clipping path would be straightforward; a resetClip() method could be done. union/replace/subtract/xor could be hard, though; certainly for mozilla to implement it, we'd have to rasterize the clip and track it separately, and convert drawing operations with a complex clip into rendering to a temporary surface and a mask by the clip surface.

Something that could alleviate the need for union/etc. would be to allow the setting of an even-odd fill rule instead of winding. This would let you do things like clip to the region left behind by punching a circle into a rectangle, which would be hard to do right now.

A better way to read colors. Return an array[4] instead of a string?
Actually the properties may fully behave like an array[4] if it is a color?
But setting to strings of format #xxxxxx and rgba(...) would still be allowed for backward compatibility?

I don't really have an opinion on this, but in what situations is reading the current color desirable? If the particular app needs to know the current color it can always track it itself; it seems like it would be simpler for apps that need this functionality to do that tracking than to change the spec.

Path API: a way to get the last point of the last subpath drawn and its orientation? Not absolutely needed, but shouldn't be too hard to implement, without breaking anything.

Sure, we could do that. What do you mean by orientation, though?

Transformations: Change the way transformations work to support the Firefox-ish / Safari-ish way? The way it is currently described in the spec is only implemented in Opera for now, and seems less versatile (and creates more overhead for implementations, it seems ;)).
(By the way, why was it choosen to be that way in the spec if it was already implemented by Apple the other way around? Is there a good reason? Does someone know?)
Also we DO need a way to get the CTM.

It's entirely possible that this totally slipped by when we were reading over the spec as Hixie wrote it; there were a few other examples of this, unfortunately. Implementing it in the way the spec states wouldn't be particularily difficult, even given an underlying graphics API that transforms the path as path commands are added -- you'd just have to buffer the path operations and then replay them whenever any drawing operation that needs the path is called, so that the path is created with the current CTM.

However, I'd much rather the spec be changed, not only due to less work for me ;) but also because as you say it's a little more flexible and IMO more straightforward for developers.

I think i have forgotten nothing important, except drawString(), but this deserves a topic on its own. ;)
BTW, i didn't want to create too much topics to avoid proliferation, but maybe a small topic for each request would have been easier to keep track of? :-/

Yeah, drawString really needs to be done; I keep meaning to propose a spec based on some stuff that I discussed with hixie a few months ago, but haven't had a chance to yet. Maybe in a few weeks.

[Jordan]

Great suggestions! Some comments, at least from my point of view. I don't know how well this will work on the forums -- it would be good to get someone from Apple and Opera at least to chime in about their implementations, and I don't know if they're following the forums -- but we'll see.

I hope they will come as well. I thought the forums were more user friendly (with ability to edit posts, and read more than one message at once), and thus we could have feedback from more people.

Resetting the clipping path would be straightforward; a resetClip() method could be done. union/replace/subtract/xor could be hard, though; certainly for mozilla to implement it, we'd have to rasterize the clip and track it separately, and convert drawing operations with a complex clip into rendering to a temporary surface and a mask by the clip surface.

resetClip() would be much appreciated. For the clipping path, it can actually mainly be "emulated" with globalCompositeOperation, wich is already implemented. Applications could use a hidden canvas as a temporary buffer, and then copy it to the actual canvas, but it would be significantly more overhead to use (and probably way slower).

Isn't there a way for implementations to reuse the code of globalCompositeOperation to do this with clipping paths? (even if new operations are not as efficient as the simple union, it would still be better than emulating them )

Something that could alleviate the need for union/etc. would be to allow the setting of an even-odd fill rule instead of winding. This would let you do things like clip to the region left behind by punching a circle into a rectangle, which would be hard to do right now.

Hm yes, though you cannot add something then substract something else with that, am i wrong?
Or do you mean that a single path could use different fill rules for each of its subpath?

I don't really have an opinion on this, but in what situations is reading the current color desirable? If the particular app needs to know the current color it can always track it itself; it seems like it would be simpler for apps that need this functionality to do that tracking than to change the spec.

I don't know.
But the current way it is right now feels overly complex, especially for a specification that aims to be simple. If a way to read colors is provided, and it is complex enough that there is a need to keep track of it by hand, then there is no point.
Also, we can hope that few applications have already implemented parsing rgba/#... from that property yet, so maybe changing what it returns to be an array would not break too many things? (and anyway if they had implemented it, updating to support the array way as well should be easier than the other way).

Sure, we could do that. What do you mean by orientation, though?

Sorry, i wanted to say the angle of the last subpath at the last point. Err... the angle of the tangent to the last subpath command drawn at the last point drawn. It's not mandatory, but it somehow makes sense to provide it if we give a way to retrieve the position of the last point. I thought the implementation is already able to calculate that because of the need for miter limits and such, so it would not be too complex as well.

We agree about transformations
Also, a getTransformMatrix() method would be nice too.

Yeah, drawString really needs to be done; I keep meaning to propose a spec based on some stuff that I discussed with hixie a few months ago, but haven't had a chance to yet. Maybe in a few weeks.

Well, you probably know way better than me about that, so i'll leave that to you.

[haustein]

Yeah, drawString really needs to be done; I keep meaning to propose a spec based on some stuff that I discussed with hixie a few months ago, but haven't had a chance to yet. Maybe in a few weeks.

Hi Vladimir,

I would really love to see some progress concerning drawString(). I have tried to write down a drawString() proposal, including some discussion of alternatives:
http://rhino-canvas.sourceforge.net/www/drawstring.html

Perhaps if you do not have the time to write a proposal for the spec right now you can just highlight some key points of your discussion in some form?

Best regards,
Stefan

[Ph0N37Ic5]

Problem 1:
It's no stright foreward way of creating filled areas with holes in them.

Code: Select all

shape:      current fill:   wanted fill:
\------|   \*******        \*******
  \     |    \******         \******
   \--| |     ******          \   **
   |\ | |     ******          *\  **
   | \| |     ******          **\ **
   |--\ |     ******          ***\**
       \|         \*              \*
        \          \               \


Code:

Code: Select all

ctx.beginPath();
ctx.moveTo(100, 100);
ctx.lineTo(150, 100);
ctx.lineTo(150, 150);
ctx.rect(110, 110, 30, 30);
ctx.fill();


Suggestion:
Add a fillMode property allowing the programmer to choose between 'full' mode, equal to the current mode(winding), and 'alternate'(odd/even) mode allowing for the fill I wanted, and also allowing a subpath to create a hole in the fill areas of other subpaths.

Processing model:
This would work pretty much equally to other similar properties, if an invalid value is entered, it is discarded/ignored without further processing, and the original value is retained. The odd/even filling mode does not treat subpaths as separate entities as such, but more as parts of the overall path.

Why browsers would implement it:
Although this is a slightly more cycle hungry way of filling than the current implementation, it makes creating a lot of polyline based objects easier for the authors. Text for example could be presented as polylines and transformed in the same way.

Why authors would want it:
As I have alredy said, this is an easier way of creating objects with holes in them. It is also a more regular way of handling paths in vector illustration programs, making it easier to export some compatible script.

Why people would be desperate for it
This is the way true-type fonts are drawn, as far as I know. It would make it easier to make export functions for vector illustration programs. I would say that this is the only good reason for implementing subpaths in the first place, apart from keeping the authors from writing fill() too many times.


Problem 2:
There is no easy way to create a non rectangular hole (transparent black) in a canvas.
This could be done by specifying a clip path and clearing with clearRect(), but with the apparent problems with clearing/discarding the clipping path, I don't really see this as a viable solution.

Suggestion:
Implement a clear() function that works like fill() but in stead of drawing clears the area specified by the path to transparent black. Further an argument could be implemented in order to create feathered edges or this could be implemented as a separate feather() function.

Processing model:
The clear() function would work exactly like fill(), with the only difference being that the marked area will be cleared to it's original state, rather than being filled with a colour. As for the feather() function would probably be more work to implement as you would need to make an alpha gradient keeping track of the nearest point on the path.

Why browsers would implement it:
The authors might want it.

Why authors would want it:
It would make it easier to make some sort of overlay that reveals something behind it. Or to make animated frames for images. It would also make it easier to use multiple canvi on top of each other as a simple layer structure.

Why people would be desperate for it:
They could create an animation with a randomly generated background. They could update the view based on difference, in stead of redrawing the whole picture. It would make it easy to cut off parts of drawn polylines.


Other stuff:

• Layer support would be nice, but might be a bit more difficult to implement
• Back buffer support would be neat, so one can draw the whole picture before doing a flip(). It seems like this is implemented to a certain extent on some browsers already, but it isn't controllable by the programmer

[Ph0N37Ic5]

Hmm, seems that my examples could be fixed with globalCompositingOperation and an extra fill(), so it was a poor example, my point still stands though, it would make things a bit easier.

I have a polyline class that would benefit greatly from this. Part of my idea is to be able to get definition strings from the server via AJAX and add or change elements in the canvas fairly easy. Sometimes it is wanted to draw shapes with holes in on top of each other.

[Philip]

It's no stright foreward way of creating filled areas with holes in them.

In this particular case, you can get the "wanted fill" by making the triangle and rectangle have opposite winding orders, like

Code: Select all

ctx.beginPath();
ctx.moveTo(150, 150);
ctx.lineTo(150, 100);
ctx.lineTo(100, 100);
ctx.rect(110, 110, 30, 30);
ctx.fill();

This is the way true-type fonts are drawn

This says they use the non-zero winding rule, rather than even-odd.

This message also suggested adding a nonzero/evenodd switch. It looks like it's a fairly standard feature of graphics APIs and should be trivial to implement in most browsers.

There is no easy way to create a non rectangular hole (transparent black) in a canvas.
This could be done by specifying a clip path and clearing with clearRect(), but with the apparent problems with clearing/discarding the clipping path, I don't really see this as a viable solution.

Which apparent problems are you referring to? I think you could do "ctx.save(); ...make path...; ctx.clip(); ctx.clearRect(...); ctx.restore()", and the clip region would be reset at the end.

"ctx.save(); ctx.globalCompositeOperation = 'destination-out'; ctx.fillStyle = '#000'; ctx.fill(); ctx.restore();" should [I think; untested...] also be equivalent to "ctx.clear()". Then you can use shadows to get the 'feather' behaviour.

[Ph0N37Ic5]

There was a whole topic on the ML about clip regions, and it's behaviour, I guees I'm just trying to add simplicity for the authors.

For the font thing, I have lost my reference, but I assume both is in use by different engines, anyway, it was more meant as an example than an argument in it self.

With the whole winding order thing, I see your point. I haven't been able to check if the winding order is coherent on all browsers though, it might be an idea to include this in the standard, so all regular paths have a predefined (clockwise?) winding order.

[kig]

Also we DO need a way to get the CTM.

+1. Might also be nice to have ctx.identity = function(){ this.setTransform(1,0,0,1,0,0) }

[coh]

After reading the wiki article stating that Apple owns patent rights to the Canvas tag, my concern is that this will lead to newer obfuscated implementations of similar ideas to Canvas, akin to the 50 billion different variates of ECMA.

Canvas should be left as an optional plugin available from Apple, such as Silverlight and Flash, as both are patented technologies as well.