Re: [whatwg] Image Collision Detection in Canvas
On Sun, Apr 4, 2010 at 1:50 PM, Saurabh Jain saur...@skjworld.com wrote: Hi, I have a proposal for adding generic image collision API in Canvas. Given two images HTMLImageElement objects and there respective x, y, clip width and clip height the API call will let you know if there's any non-transparent pixel (any opaque or translucent pixel) in one image's clipping region that overlaps a non-transparent pixel in another image's clipping region. The clipping region defined by this API call is for local use only for this purpose. Why not add a general BitBlt library on top of typed arrays (1) instead? This could also be useful for other applications, e.g. web-based photo editors... Stefan 1) https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html This API will be useful for game programmers. I am author of India's first book on J2ME and have been developing mobile games since 2002. I have through personal experience observed that this pixel level collision at native level is required for game developers to build games easily. What I am referring to is a kind of generic pixel level collision. People are free to develop there own complex collision mechanisms for complex games but small teams composed of new game developers find image collision detection implementation the most difficult concept in the whole game development process to grasp. Also pixel level checking for two 100 pixel x 100pixel images will involve lot of execution time if done at JavaScript level since up to 1 checks may have to be performed. Native browser support can speed things a lot. Similar thing happened in J2ME where before MIDP 2.0 people had hard time to do pixel level collision both due to programming complexity and execution issues. Saurabh Jain Director SKJ Technologies Private Limited http://www.skjworld.com Author : Mobile Phone Programming using Java ME (J2ME) http://library.skjworld.com/mobile-technology/java/java-me -- Stefan Haustein Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ; Registered in England Number: 3977902
Re: [whatwg] canvas, img, file api and blobs
On Wed, Feb 17, 2010 at 8:35 AM, Stef Epardaud s...@epardaud.fr wrote:
On Tue, Feb 16, 2010 at 07:25:34PM +, Stefan Haustein wrote:
We've been getting pretty good traction on Vlad's ArrayBuffers
proposal,
which was taken from the WebGL spec. Our current plan is to change
the
names in the browsers (WebKit, Chrome and Mozilla) to the non-WebGL
specific names Vlad proposes in his spec. We'd really like this to
be the
one true binary data access mechanism for HTML. We're talking to
the
File API guys about this and I think this API can be adapted in all
the
other places as well.
As far as performance goes, can you point me at some quantitative
data?
When you say it's an orders-of-magnitude bottleneck, what are you
comparing it to? The API is very new and we certainly want to
improve it
for the various purposes it can be put to. We've even talked about
optimizations inside the JS implementations to improve access
performance.
If we can get something akin to Java's System.arraycopy (
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#arraycopy%28java.lang.Object,%20int,%20java.lang.Object,%20int,%20int%29
) then the ArrayBuffer proposal would work for me :)
If we cannot copy ArrayBuffer ranges by blocks in an effecient manner,
then it's going to be very limiting.
The array based set method would let you do this:
function arrayCopy(src, spos, dst, dpos, len) {
dst.set(src.slice(spos, len), dpos);
}
If I understand Vladimir's response correctly, its omission from his
ECAMScript proposal is unintentional (it is present in the WebGL spec) and
will be fixed.
Stefan
--
Stéphane Epardaud
--
Stefan Haustein
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ; Registered in England Number: 3977902
Re: [whatwg] canvas, img, file api and blobs
On Wed, Feb 17, 2010 at 1:04 PM, Stefan Haustein haust...@google.comwrote:
On Wed, Feb 17, 2010 at 8:35 AM, Stef Epardaud s...@epardaud.fr wrote:
On Tue, Feb 16, 2010 at 07:25:34PM +, Stefan Haustein wrote:
We've been getting pretty good traction on Vlad's ArrayBuffers
proposal,
which was taken from the WebGL spec. Our current plan is to change
the
names in the browsers (WebKit, Chrome and Mozilla) to the
non-WebGL
specific names Vlad proposes in his spec. We'd really like this to
be the
one true binary data access mechanism for HTML. We're talking to
the
File API guys about this and I think this API can be adapted in all
the
other places as well.
As far as performance goes, can you point me at some quantitative
data?
When you say it's an orders-of-magnitude bottleneck, what are you
comparing it to? The API is very new and we certainly want to
improve it
for the various purposes it can be put to. We've even talked about
optimizations inside the JS implementations to improve access
performance.
If we can get something akin to Java's System.arraycopy (
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#arraycopy%28java.lang.Object,%20int,%20java.lang.Object,%20int,%20int%29
) then the ArrayBuffer proposal would work for me :)
If we cannot copy ArrayBuffer ranges by blocks in an effecient manner,
then it's going to be very limiting.
The array based set method would let you do this:
function arrayCopy(src, spos, dst, dpos, len) {
dst.set(src.slice(spos, len), dpos);
}
If I understand Vladimir's response correctly, its omission from his
ECAMScript proposal is unintentional (it is present in the WebGL spec) and
will be fixed.
Stefan
p.s. This would probably also address some of the reference vs. copy issues
raised in section 5 (
http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html#5 )
--
Stéphane Epardaud
--
Stefan Haustein
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ; Registered in England Number: 3977902
--
Stefan Haustein
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ; Registered in England Number: 3977902
Re: [whatwg] canvas, img, file api and blobs
On Tue, Feb 16, 2010 at 10:08 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2010, at 12:13 AM, Jonas Sicking wrote: Absolutely! I definitely agree that we need a type like this. The sooner the better. On that note, do you know what the latest status is within ECMA on this? I know you made a proposal on the webapps list (or was it here?), did that go anywhere? I made my proposal to ECMA TC-39 (the relevant committee). I will try to polish it and request it as an agenda item for the next face-to-face (in March). Independently, WebGL's typed arrays have been proposed. Hi Maciej, do you have a link to your proposal? Stefan However I suspect it'd be useful to be able to extract as Blob object as well, for storing in places like databases or to extract a url. If we end up with APIs in some places that only take Blobs as input, then we should probably have easy ways to make a Blob out of a binary data object or a string (like StringStreams in other languages). Regards, Maciej -- Stefan Haustein Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ; Registered in England Number: 3977902
Re: [whatwg] canvas, img, file api and blobs
On Tue, Feb 16, 2010 at 5:09 PM, Stef Epardaud s...@epardaud.fr wrote: On Tue, Feb 16, 2010 at 11:39:31AM -0500, Joel Webber wrote: And in particular, does it bear any resemblance to the WebGLArray interfaces, as proposed in ([3]http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html)? I'm particularly concerned with the interfaces among all these different subsystems (WebGL, Canvas, XHR, File, etc., as being discussed on this thread) that want to operate on binary data. We've found that getting data from XHR to WebGL via WebGLArrays to be a huge (read: probably orders-of-magnitude) bottleneck; but being able to slice mesh and texture data out of arrays directly from XHR responses would completely fix this. The TypedArray proposal seems to lack a way to efficiently copy ranges of bytes from one array to another. This is essential if we want to resize arrays (which is going to be needed if we want to add EXIF data to an image for example). Copying byte by byte would be unacceptable. It is mentioned in section 5, but a proposed solution is a constructor, which is a bit restrictive (how would we concatenate two byte arrays?) The WebGL spec has a corresponding set method (see https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#5.14.3.3): set(array, offset) Set multiple values, reading input values from the array. The optional offset value indicates the index in the current array where values are written. If omitted, it is assumed to be 0. If the offset plus the length of the given array is out of range for the current WebGLArray, an exception is raised. Not sure why this was omitted in Vladimir's version... -- Stéphane Epardaud -- Stefan Haustein Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ; Registered in England Number: 3977902
Re: [whatwg] canvas, img, file api and blobs
On Tue, Feb 16, 2010 at 6:22 PM, Chris Marrin cmar...@apple.com wrote: On Feb 16, 2010, at 9:00 AM, Eric Carlson wrote: Chris - Welcome to the HTML5 WG email torrent ;-) Here is a message that you might actually care to read. eric Begin forwarded message: From: Joel Webber j...@google.com Date: February 16, 2010 8:39:31 AM PST To: Stefan Haustein haust...@google.com Cc: Maciej Stachowiak m...@apple.com, wha...@whatwg.org, Jonas Sicking jo...@sicking.cc, Stef Epardaud s...@epardaud.fr Subject: Re: [whatwg] canvas, img, file api and blobs On Tue, Feb 16, 2010 at 7:38 AM, Stefan Haustein haust...@google.com wrote: On Tue, Feb 16, 2010 at 10:08 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2010, at 12:13 AM, Jonas Sicking wrote: Absolutely! I definitely agree that we need a type like this. The sooner the better. On that note, do you know what the latest status is within ECMA on this? I know you made a proposal on the webapps list (or was it here?), did that go anywhere? I made my proposal to ECMA TC-39 (the relevant committee). I will try to polish it and request it as an agenda item for the next face-to-face (in March). Independently, WebGL's typed arrays have been proposed. Hi Maciej, do you have a link to your proposal? And in particular, does it bear any resemblance to the WebGLArray interfaces, as proposed in ( http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html)? I'm particularly concerned with the interfaces among all these different subsystems (WebGL, Canvas, XHR, File, etc., as being discussed on this thread) that want to operate on binary data. We've found that getting data from XHR to WebGL via WebGLArrays to be a huge (read: probably orders-of-magnitude) bottleneck; but being able to slice mesh and texture data out of arrays directly from XHR responses would completely fix this. We've been getting pretty good traction on Vlad's ArrayBuffers proposal, which was taken from the WebGL spec. Our current plan is to change the names in the browsers (WebKit, Chrome and Mozilla) to the non-WebGL specific names Vlad proposes in his spec. We'd really like this to be the one true binary data access mechanism for HTML. We're talking to the File API guys about this and I think this API can be adapted in all the other places as well. As far as performance goes, can you point me at some quantitative data? When you say it's an orders-of-magnitude bottleneck, what are you comparing it to? The API is very new and we certainly want to improve it for the various purposes it can be put to. We've even talked about optimizations inside the JS implementations to improve access performance. If we can get a webgl buffer from an XHR response (which would be a *huge* improvement), we'd still need to parse the binary data when decoding JPEG headers, protocol buffers etc. Constructing ints / longs from bytes in Javascript will probably be slow, so in addition to the typed arrays, we'd love to have some kind of access that would be similar to Java's DataInput (+DataOutput, see http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInput.html ), but with endianess support Stefan - ~Chris cmar...@apple.com -- Stefan Haustein Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ; Registered in England Number: 3977902
Re: [whatwg] Opera canvas bug?
Hi Ian, concerning when to apply transformations, I think it makes much sense to let the spec reflect the current reality of Safari and Firefox instead of the other way around for the following reasons: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010937.html The referenced MDC clock example is available at: http://developer-stage.mozilla.org/en/docs/Canvas_tutorial:Basic_animations Best regards, Stefan Ian Hickson wrote: On Mon, 2 Oct 2006, Tim Johansson wrote: Thank you for the bug reports. I have some comments on the second test case. The cause of this is that Opera applies the transform in the fill command (which is how I read the current spec, but it is not very clear). When the fill is called the scale is already reset, so the rect is drawn untransformed. I would like some clarification in the spec on when the transformation is supposed to be applied. Opera does this per spec. I've tried to clarify it (let me know if it still needs work, though). Firefox and Safari have bugs on this. Here are some more tests for you: http://www.hixie.ch/tests/adhoc/html/canvas/ Cheers,
Re: [whatwg] Web Documents off the Web (was Web Archives)
Hi Tyler, I like the idea very much, for instance for having a copy of the CSS spec on my laptop without the need of an Internet connection while commuting - When I save a page with Safari, Firefox cannot read it. - When saving stuff with Firefox, I have to deal with both, the HTML file and the resource folder - It would be easy to write a nice wget-like utility that creates a single file. - A zip based format is still usable for browsers that do not support it, one would just needs to unpack the file. Best regards, Stefan Haustein Tyler Keating wrote: Hi, I'm bringing this up again with a different tact, because the more that I think about it, the more I believe it has the ability to significantly change the perception and application of HTML and I would really like to keep the discussion alive. In the previous thread, I proposed a standard for archiving web sites into a single ZIP archive with a unique file extension and although it didn't get any outright negative feedback, it didn't drum up too much excitement either. If you can bear with me, I'd like to describe the idea again in a slightly different light. Take for example, web-based presentations vs. PowerPoint from an average user's point-of-view. I can create an incredibly dynamic presentation based on HTML, JavaScript, CSS, SVG, etc., but I can't easily share it with anyone unless it is served (I can't easily send it to them). On the other hand, I can create an incredibly dynamic presentation using PowerPoint, but I can't easily share it with anyone unless I send them the file and they also have PowerPoint (I can't easily serve it).* For another example, which relates to my modest experience, I've created a simple Quotes/Sales/Invoices web app for a friend and have come across similar issues trying to resolve the served file model with the local file model. Without going into too much detail, assume that there is sufficient reason why a file copy of the web page is needed (in this case because my friend's customers can't use the app directly). How should the user get copies of web documents to be sent or saved to disk? Instead of describing all of the various options of saving it to some kind of browser proprietary archive, sending HTML email, creating an HTML-to-PDF converter or some other time-consuming non-user friendly method, let's look at an ideal solution. Imagine this: An HTML based document ZIP compressed into a single file could be uploaded as is to the server. Clicking on a link to the file would probably download, decompress and open the file in the browser seamlessly and, even better, right-clicking on the link instead and choosing Download Linked File would download the same nice small single file.** Double clicking that file would open it in any browser identically as to the served version. The identical format and behaviour of the web document and the file document presents the best user experience. Instead of saving a representation of the web document, you are saving THE web document. The question is, why do we only think of HTML with respect to the web and why are HTML-based documents constrained to being served? This is the meat of my argument. Browsers have no issue opening a file URI, but humans have an issue dealing with a directory of .html files versus, say, a single .ppt file. Humans will soon also have issues viewing and serving ODF and OOXML files, I might add, but still won't have issues viewing and serving HTML files. After the little bit of discussion from the first thread, I believe that the solution is indeed a near clone and more complete version of the Widgets 1.0 specification ( http://www.w3.org/TR/WAPF-REQ/ ) as something different and as part of HTML, specifying how to package entire web documents as zip compressed archives using a unique file extension. In reality, compared to all of the other work being done on HTML, I believe this would be very simple to specify and should be very simple to implement. Please give this some thought. I appreciate your comments. Tyler Keating CEO Concept Digital Inc. -- don't be impressed, it's just me * I could export an HTML version to be served, but I can't share both ways with the same file and this means I have two versions of the same presentation to work with. Again, the average user (my mom) isn't going to be serving files created on their desktop any time too soon, since she has just barely grasped email attachments. ** Containing any number of HTML, XHTML, CSS, image or other files inside of it invisible to the average user.
Re: [whatwg] Canvas suggestions
Jordan OSETE wrote: Yes, but there are complex shapes that can be made really easier to draw this way. On the other hand, the way the current specification works allows to construct a single shape once, and draw it in different ways around, by just modifying the transform attribute... It would be nice to have both, being able to use transformations independantly for drawing and constructing the path. I don't know if it would be very hard to implement or not? (well, obviously not for the mozilla project, since they already have it ;) Hi Jordan, in my opinion, preserving the path for re-use does not buy much: Path construction at this level is just appending a few coordinates and meta-information to an array. Since there is no knowledge about future transformations, one needs to keep the original coordinates instead of the device coordinates, and it is not possible to calculate segment count for Bezier curves etc. Moreover, if the path is not re-used, keeping the original coordinates is unnecessary overhead. I doubt reusing just a simple path with different transformations is a significant use case that justifies this overhead, and most implementations seem not to support it anyway. So I would prefer to keep it simple and to see the spec reflect the current reality over having both or incompatible changes in implementations. Best regards, Stefan
Re: [whatwg] Canvas suggestions
Maciej Stachowiak wrote: You can achieve relative moves by doing a translation to the current point when drawing; this is a more general version of what your pathBase property would do. Hi, the WHATWG spec says you cannot do so (section 3.14.11.1.8): Note: The transformation is applied to the path when it is drawn, not when the path is constructed. Thus, a single path can be constructed and then drawn according to different transformations without recreating the path. BTW: The Mozilla Developer Connection clock sample relies on applying transformations at construction time, but runs fine in Firefox 2, so at least the Firefox implementation seems to be non-conforming in this respect. In my opinion, relative moves easily become confusing in the case of Bezier Curves (what is the point of reference for the third and fourth coordinate pair?), and additional methods would basically be redundant without significant gains in functionality or speed. However, a faster way to set (and get) the line or fill color that does not involve parsing / object construction would be appreciated very much. BTW2: What about drawString(), I'd really love to see this one... Best regards, Stefan Haustein
Re: [whatwg] [WebApps] canvas transform()/setTransform()
Hi, could somebody please clarify whether the unusual parameter order is intended -- or simply a bug in the specification? Best regards, Stefan 黒澤剛志(KUROSAWA, Takeshi) wrote: Dear WHATWG, Web Application 1.0 adds the transform() and the setTransform() to the canvas 2d context. The conversion of the arguments of these methods to the matrices is described in the section 3.14.6.1.2. The transform(m11, m12, m21, m22, dx, dy) method must multiply the current transformation matrix with the matrix described by: m11 m12 dx m21 m22 dy 0 0 1 The setTransform(m11, m12, m21, m22, dx, dy) method... - http://www.whatwg.org/specs/web-apps/current-work/#transform However, this is repugnant. And it isn't compatible with many graphics systems. So the matrix should be m11 m21 dx m12 m22 dy ... (b) 0 0 1 In addtion, the rhino-canvas implements both methods. It uses the matrix (b). http://rhino-canvas.sourceforge.net/ regards.
Re: [whatwg] General request regarding feature requests -- drawString()
Hi, I have updated the drawString() feature request accordingly: http://rhino-canvas.sourceforge.net/www/drawstring.html Best regards, Stefan Ian Hickson wrote: I'm happy to see the increased interest in HTML5 recently -- especially with the amazing work Lachlan, Henri, and others are doing with the blog, the validator, feedback, and so forth. Since the volume of feature requests is only going to increase in the near future, I'd like to request that feature requests be clear and include at least the following information: * What is the problem you are trying to solve? * What is the feature you are suggesting to help solve it? * What is the processing model for that feature, including error handling? This should be very clear, including things such as event timing if the feature involves events, how to create graphs representing the data in the case of semantic proposals, etc. * Why do you think browsers would implement this feature? * Why do you think authors would use this feature? * What evidence is there that this feature is desparately needed? Obviously, we want to keep the language as simple as possible. That means not everyone will get what they want. Having clear answers to the questions above will help all of us work out what is most important. Cheers,
Re: [whatwg] Still beating the drawString() dead horse...
Mathieu HENRI wrote: Stefan Haustein wrote: Hi, I have tried to sum up the requirements for CanvasRenderingContext2D.drawString() at http://rhino-canvas.sf.net/www/drawstring.html The page contains an API proposal based on the Font/TextStyle object approach that meets all those requirements, and also some motivation why I have implemented this approach and not one of the alternatives discussed here. I still think by introducing the drawString() method into Canvas we are opening the same can of worms that was open in SVG. If we go that way we will need a drawParagraph() method to draw multi line strings or blocks of text with wrapping and a bounding width. We also need to be able to stylize the text, i.e. changing the font-weight / color / font-style ... of any word. Hi Mathieu, I do no see how adding drawString() implies that drawParagraph() must be added, too. In fact, you can implement all that stuff yourself in Javascript in a way that suits your application data. Comparing SVG and Canvas is like comparing apples and oranges. Instead of comparing Canvas to a declarative approach, why not compare it to the Java Canvas class? Java 1.1 did not have any drawParagraph() method, only drawString(), but you could still implement a whole text editor. The list goes on and on ... and HTML and CSS already cover it all. HTML and CSS do not cover access to the font metrics. If HTML and CSS are suitable for your use case, why not stick with HTML and CSS in the first place? What is the use case for drawElement()? For applications such as labels in dynamic maps, graphs, game scores and data visualization, drawElement() simply does not seem adequate. The HTMLElement.drawElement() method should be no problem to implement since userAgents already do render HTMLElements. Being able to tender HTML elements does not imply that it is simple to render HTML elements out of context or multiple times. Even if it may be simple in one particular browser implementation, that does not imply that it is simple in others. Having it return an ImageData object will make it insanely simple to manipulate in Canvas. Memory usage and slowness will also become insane, and upscaling will become insanely ugly. The text elements/contents can easily be in the fall back content of the Canvas tag thus keeping it accessible. If the text is usable on its own, it is probably better placed in regular HTML content. Getting the bounding box of an HTMLElement is no problem either in JavaScript. And applying gradients and patterns can be done using a fillRect() with the appropriate globalCompositeOperation. The bounding box does not help to align a the beaseline of a label with a given coordinate. Everything (almost) is there. Let's not re-invent a square wheele The problem here is almost. All other graphics libraries seem to roll fine with this square wheel, so perhaps it is a bit rounder than you suggest? No, SVG is not a graphics library Best regards, Stefan
Re: [whatwg] Still beating the drawString() dead horse...
Arve Bersvendsen wrote:
Let's see. CSS and an element interface provides:
1) Specified and predictable white-space handling
2) Specified and predictable font and font-size handling (fallbacks,
relative and absolute sizes)
3) Specified and predictable line-height handling
4) Inline formatting
5) Color handling
A drawString would have to support all of these to be useful, and by
that time you'll have reinvented more of CSS than you'd want to.
It is not necessary to reinvent any CSS, CSS can be used for 2), so the
predictability is the same. The remainder is out of scope for
drawString() or handled by existing canvas mechanisms, and it is simply
not true that drawString() is not usable without those features. I have
provided several use cases for drawString() in earlier posts (labels in
graph/map/data visualization), and I still do not see any use case that
would justify the added weight and complexity of drawElement().
var myEle = document.createElement('p');
myEle.textContent(Hello \nWorld);
// Or choose any other method of attaching style attributes to
elements.
myEle.style = color: blue; white-space: pre; font-size: 12px;
line-height: 2; width: 100px; height: 100px;
// ...
myCanvas2dContext.drawImage(myEle.drawElement(),0,0)
Not too complicated.
The implied overhead makes me feel extremely uncomfortable with this
approach.
Also, what happens if the text does not fit in 100x100 px? How do I
figure out how much space the text actually occupies without starting to
look at Image pixel values -- I may e.g. want to reduce the map detail
level when the user increases the text size...
If you have drawElement() already implemented in Opera, and
drawElement() is sufficient powerful, it should be easy enough to
provide a simple drawString() for those who like to keep simple things
simple...
Best regards,
Stefan
[whatwg] Still beating the drawString() dead horse...
Hi, I have tried to sum up the requirements for CanvasRenderingContext2D.drawString() at http://rhino-canvas.sf.net/www/drawstring.html The page contains an API proposal based on the Font/TextStyle object approach that meets all those requirements, and also some motivation why I have implemented this approach and not one of the alternatives discussed here. Best regards, Stefan
Re: [whatwg] Canvas lack of drawString method
Hi Joao,
the Canvas API is already using CSS-like color definitions, so any
Canvas API implementation is already forced to implement some small bits
of CSS. It would be just consistent to describe a font request in a
similar way. Not using CSS names and values for describing font
properties would mean to re-invent the wheel. Why should I learn new
names for font properties if I could simply use the ones I already know
from CSS?
Of course, in a non-browser environment, one would not be able to assign
a style by reference to a style sheet.
I have implemented most of the Canavas API for the Rhino Javascript
interpreter (significant omissions are darker, lighter and arcTo), so if
you are interested in non-browser Canvas API stuff, you may want to take
a look at http://rhino-canvas.sf.net
I did not include any kind of drawString() yet -- I am still hoping for
some kind of consensus on the list... :)
Best regards,
Stefan
Concerning
Joao Eiras wrote:
I think mixing CSS and Canvas is a bad idea.
You could develop an application which would implement the canvas APi,
and be easily programed with ecmascript or java.
Adding this kind of feature would force the implementor to support CSS
too, at least partially.
Stefan Haustein [EMAIL PROTECTED] escreveu:
Hi David,
I think it is very important to be able to determine the rendered
size of the text. Otherwise, there is no reliable way to make sure
things do not overlap. Also, some kinds of applications (flash-like
effects, labels expressing weight or distance, WYSIWYG text editors)
may require variable font sizes or styles.
What do you think about
context.textStyle = barchart; // style by reference
context.textStyle = { // set style directly
font-size: 8px,
font-family: Monaco, monospace
}
context.drawText(x,y,string); context.getFontAscent();
context.getFontDescent();
context.getFontLeading();
context.getTextWidth(string);
Best regards,
Stefan
David Hyatt wrote:
I think a drawText method would be extremely useful.
Rather than specifying stylistic information explicitly (via a font
object), I'd use a special parenthetical pseudo-element. thus
allowing the author to specify the style as for any other element on
a page something like this...
canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}
and then the API would be something like:
drawText(y-coord of baseline, barchart, myText)
and letter-spacing/word-spacing would work, small-caps would work,
text-shadow would work, etc. etc.
fitTextToPath might be an interesting API too.
dave
([EMAIL PROTECTED])
On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:
Gervase Markham wrote:
Stefan Haustein wrote:
I think drawElement(elem) opens up a whole new can of worms:
- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label
positioning?
- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be
difficult to read
- it needs to be specified whether css properties are inherited
from the parent element of elem.
- how much horizontal/vertical space is drawElement permitted to
use for rendering?
The answer to all of these things is that the browser renders all
the elements in the page as it would if the canvas were not
supported and the alternate content were being used. It then
basically screenshots the area corresponding to the element (yes,
I know this needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except
from the last one. You can specify some CSS constraints, but how do
you determine the actual rendering height of a text box with a
specific width? How do you determine the pixel position of the
baseline? The cross reference and the dynamic text issues are not
addressed at all.
Like I said, we want to leverage the browser's deep and complex
knowledge of text rendering as much as possible, and just take the
resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex than
it seems because of problems with internal data structures for
rendering hints and implicitly introducing the ability to render
the same element twice.
- what happens with contained plugins, canvas elements,
self-references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But we
could put limits on it like e.g. no plugins, no object, and
still have something very useful for rendering text.
So I assume we agree that the element rendering proposal would
still need significant specification work and is probably much more
difficult to implement. The element rendering approach may make
working with bulk text simpler, but this case is already handled
quite fine by HTML outside the Canvas element. By asking for too
much, we may
Re: [whatwg] Canvas lack of drawString method (p.s.)
p.s.: However, I would still prefer an API design that keeps it simple to add those methods later. ^ those = the metrics query methods, of course Deleted some text block and then it became a bit out of context
Re: [whatwg] Canvas lack of drawString method
Charles Iliya Krempeaux wrote:
I believe it starts to gets more complex when you get into
globalization. (Not that I'm an expert on that, but) More
thought may be needed to be put into this to make this work in a
global sense (and not just with roman-based alphabets like ours.)
Hi Charles,
what precisely are you suggesting? Are some characters missing from UTF?
Are the writing direction properties of CSS not sufficient to cover some
writing directions?
To my knowledge concerning baseline/ascent/descent, non latin characters
are equal (kyrillic, greek) or simpler, but of course I may be
overlooking something, and I am always happy to learn anything new about
I18N and foreign languages (if it is a bit more specific than I belive
there may be problems).
Best regards,
Stefan
See ya
On 10/25/06, *Stefan Haustein* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi David,
of course adding only textStyle and drawText() is much better than
nothing at all! :)
However, I would still prefer an API design that keeps it simple
to add
those methods later. Perhaps they could be included and simply return
null if the requested information is not available (e.g. for a
dumb EPS
render target?). Also, if we do not have access to font metrics, I
think
we need an additional parameter for drawText() that specifies the
alignment of the text relative to the reference point, as
illustrated in
the image below:
http://www.developer.com/img/articles/2002/12/26/03fig12.jpg
http://www.developer.com/img/articles/2002/12/26/03fig12.jpg
Best regards,
Stefan
David Hyatt wrote:
I'm very reluctant to expose font metrics and information (yet). I
think once you start getting into specifying fonts, you open up
a can
of worms that would make this sort of API addition a lot harder.
dave
On Oct 24, 2006, at 4:05 PM, Stefan Haustein wrote:
Hi David,
I think it is very important to be able to determine the rendered
size of the text. Otherwise, there is no reliable way to make sure
things do not overlap. Also, some kinds of applications (flash-like
effects, labels expressing weight or distance, WYSIWYG text
editors)
may require variable font sizes or styles.
What do you think about
context.textStyle = barchart; // style by reference
context.textStyle = { // set style directly
font-size: 8px,
font-family: Monaco, monospace
}
context.drawText(x,y,string); context.getFontAscent();
context.getFontDescent();
context.getFontLeading ();
context.getTextWidth(string);
Best regards,
Stefan
David Hyatt wrote:
I think a drawText method would be extremely useful.
Rather than specifying stylistic information explicitly (via a
font
object), I'd use a special parenthetical pseudo-element. thus
allowing the author to specify the style as for any other
element on
a page something like this...
canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}
and then the API would be something like:
drawText(y-coord of baseline, barchart, myText)
and letter-spacing/word-spacing would work, small-caps would
work,
text-shadow would work, etc. etc.
fitTextToPath might be an interesting API too.
dave
([EMAIL PROTECTED] mailto:[EMAIL PROTECTED])
On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:
Gervase Markham wrote:
Stefan Haustein wrote:
I think drawElement(elem) opens up a whole new can of worms:
- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label
positioning?
- there are probably issues with dynamically calculated
text values
- code with lots of cross references to elements will be
difficult to read
- it needs to be specified whether css properties are inherited
from the parent element of elem.
- how much horizontal/vertical space is drawElement
permitted to
use for rendering?
The answer to all of these things is that the browser
renders all
the elements in the page as it would if the canvas were not
supported and the alternate content were being used. It then
basically screenshots the area corresponding to the element
(yes,
I know this needs careful definition) and draws that into
the canvas.
I do not see how your statement answers any of my questions
except
from the last one. You can specify some CSS constraints, but
how do
you determine the actual rendering height of a text box with a
specific width? How do you determine the pixel position of the
baseline? The cross
Re: [whatwg] Canvas lack of drawString method
Hi David,
I think it is very important to be able to determine the rendered size
of the text. Otherwise, there is no reliable way to make sure things do
not overlap. Also, some kinds of applications (flash-like effects,
labels expressing weight or distance, WYSIWYG text editors) may require
variable font sizes or styles.
What do you think about
context.textStyle = barchart; // style by reference
context.textStyle = { // set style directly
font-size: 8px,
font-family: Monaco, monospace
}
context.drawText(x,y,string);
context.getFontAscent();
context.getFontDescent();
context.getFontLeading();
context.getTextWidth(string);
Best regards,
Stefan
David Hyatt wrote:
I think a drawText method would be extremely useful.
Rather than specifying stylistic information explicitly (via a font
object), I'd use a special parenthetical pseudo-element. thus allowing
the author to specify the style as for any other element on a page
something like this...
canvas::canvas-text(barchart)
{
font-size: 8px;
font-family: Monaco, monospace;
}
and then the API would be something like:
drawText(y-coord of baseline, barchart, myText)
and letter-spacing/word-spacing would work, small-caps would work,
text-shadow would work, etc. etc.
fitTextToPath might be an interesting API too.
dave
([EMAIL PROTECTED])
On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:
Gervase Markham wrote:
Stefan Haustein wrote:
I think drawElement(elem) opens up a whole new can of worms:
- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label
positioning?
- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be difficult
to read
- it needs to be specified whether css properties are inherited
from the parent element of elem.
- how much horizontal/vertical space is drawElement permitted to
use for rendering?
The answer to all of these things is that the browser renders all
the elements in the page as it would if the canvas were not
supported and the alternate content were being used. It then
basically screenshots the area corresponding to the element (yes, I
know this needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except
from the last one. You can specify some CSS constraints, but how do
you determine the actual rendering height of a text box with a
specific width? How do you determine the pixel position of the
baseline? The cross reference and the dynamic text issues are not
addressed at all.
Like I said, we want to leverage the browser's deep and complex
knowledge of text rendering as much as possible, and just take the
resulting pixel output as it would be shown to the user.
- the implementation in actual browsers may be more complex than it
seems because of problems with internal data structures for
rendering hints and implicitly introducing the ability to render
the same element twice.
- what happens with contained plugins, canvas elements,
self-references... all this stuff needs to be well-defined
Indeed. I know it's easy to state and there are edge cases. But we
could put limits on it like e.g. no plugins, no object, and still
have something very useful for rendering text.
So I assume we agree that the element rendering proposal would still
need significant specification work and is probably much more
difficult to implement. The element rendering approach may make
working with bulk text simpler, but this case is already handled
quite fine by HTML outside the Canvas element. By asking for too
much, we may end up with nothing at all.
Andrew has provided a clear and simple proposal that can easily be
implemented without too much consideration of side effects. Putting
labels on maps, precise text positioning, starwars-like 3d scrolling
text, labels for game characters or in physics simulations, all the
stuff that could only be done in a canvas element, is trivial to
implement with the drawText() approach, but seems much more complex
or impossible with the element rendering approach.
Moreover, drawElement() would not solve the drawText problem for
non-browser environments such as Rhino.
How are we anticipating canvas might be used in a non-browser
context?
Canvas and some other parts of the spec (e.g. connections) may make a
lot of sense for Javascript outside of the browser context. This may
be outside of the scope of WHATWG, but if we can take out some
building blocks and use them somewhere else, this is at least a sign
of good and modular API design.
Best regards,
Stefan
Re: [whatwg] Canvas lack of drawString method
Gervase Markham wrote: Stefan Haustein wrote: I think drawElement(elem) opens up a whole new can of worms: - how would an application determine the size of the text box? - where is the baseline position, needed for exact axis label positioning? - there are probably issues with dynamically calculated text values - code with lots of cross references to elements will be difficult to read - it needs to be specified whether css properties are inherited from the parent element of elem. - how much horizontal/vertical space is drawElement permitted to use for rendering? The answer to all of these things is that the browser renders all the elements in the page as it would if the canvas were not supported and the alternate content were being used. It then basically screenshots the area corresponding to the element (yes, I know this needs careful definition) and draws that into the canvas. I do not see how your statement answers any of my questions except from the last one. You can specify some CSS constraints, but how do you determine the actual rendering height of a text box with a specific width? How do you determine the pixel position of the baseline? The cross reference and the dynamic text issues are not addressed at all. Like I said, we want to leverage the browser's deep and complex knowledge of text rendering as much as possible, and just take the resulting pixel output as it would be shown to the user. - the implementation in actual browsers may be more complex than it seems because of problems with internal data structures for rendering hints and implicitly introducing the ability to render the same element twice. - what happens with contained plugins, canvas elements, self-references... all this stuff needs to be well-defined Indeed. I know it's easy to state and there are edge cases. But we could put limits on it like e.g. no plugins, no object, and still have something very useful for rendering text. So I assume we agree that the element rendering proposal would still need significant specification work and is probably much more difficult to implement. The element rendering approach may make working with bulk text simpler, but this case is already handled quite fine by HTML outside the Canvas element. By asking for too much, we may end up with nothing at all. Andrew has provided a clear and simple proposal that can easily be implemented without too much consideration of side effects. Putting labels on maps, precise text positioning, starwars-like 3d scrolling text, labels for game characters or in physics simulations, all the stuff that could only be done in a canvas element, is trivial to implement with the drawText() approach, but seems much more complex or impossible with the element rendering approach. Moreover, drawElement() would not solve the drawText problem for non-browser environments such as Rhino. How are we anticipating canvas might be used in a non-browser context? Canvas and some other parts of the spec (e.g. connections) may make a lot of sense for Javascript outside of the browser context. This may be outside of the scope of WHATWG, but if we can take out some building blocks and use them somewhere else, this is at least a sign of good and modular API design. Best regards, Stefan
Re: [whatwg] Canvas lack of drawString method
Hi Andrew, I agree that the structure of your proposal is better, the Font object is not really needed. However, I think getAscent() is not sufficient, we should also add getLeading() and getDescent(): This would allow us to determine the total line height (leading+ascent+descent) and the baseline position (leading+ascent): http://docs.rinet.ru/UJ11/art/17/17fig08n.jpg The total line height is important since it constitutes the minimum vertical distance from baseline to baseline (Accents on uppercase letters will be placed in the leading area, and they must not overlap with the descent from the previous line). The baseline position is important for text alignment when using different fonts/styles in a single line. Of course we, could add getBaselinePosition() and getHeight() instead of some of the other methods, but including the three most basic values seems to be a consistent approach (simple to remember) and all other values can be calculated by summing them up somehow (no differences needed). Best regards, Stefan Andrew Fedoniouk wrote: - Original Message - From: Stefan Haustein [EMAIL PROTECTED] Cc: WHAT Working Group Mailing List [EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 2:50 PM Subject: Re: [whatwg] Canvas lack of drawString method Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont(String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight(); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); In fact separate Font object is not needed in most cases. It is enough to have simple setFont function for that. I've found that following five methods of Graphics are just enough: Graphics.setFont(FontOrFamilyName, size, weight, ...); Graphics.setTextAlignment(horizontal, vertical); Graphics.getFontAscent(); Graphics.getTextWidth(string); Graphics.drawText(x,y,string); For example, below is code fragment drawing this: http://www.terrainformatica.com/sciter/screenshots/sciter-graphics-text.jpg var gfx = sandbox.graphics(#v2d); var width = sandbox.box(#width); var height = sandbox.box(#height); gfx.lineWidth(1.0); gfx.lineJoin = Graphics.JOIN_ROUND; gfx.lineColor(Graphics.RGBA(0x7F,0,0)); gfx.fillRadialGradient(width/2, height/2, height/2, Graphics.RGBA(0xFF,0xFF,0), Graphics.RGBA(0xFF,0,0) ); gfx.setTextAlignment(Graphics.ALIGN_CENTER,Graphics.ALIGN_CENTER); gfx.setFont(Verdana, 64.0); gfx.text(width/2, height/2, Text in Sciter!); --- drawText shall use outline and fill attributes that Graphics already has. It also shall follow all transformation attributes. It is highly non desirable to have separate objects like brushes and fonts with non-deterministic life span. Especially in GC environments. Andrew Fedoniouk. http://terrainformatica.com Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method
Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont(String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight(); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method (p.s.)
p.s.: To simplify coping with changing font sizes, it probably makes sense to add an align parameter (left|center|right top|center|baseline|bottom) to the drawString call... Stefan Haustein wrote: Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont(String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight(); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method (p.s.)
James, the second image exposes exactly the problem that an alignment parameter would solve: TR and 1/2pi could be drawn aligned baseline right to the references point on the y-axis. 0.97 and pi could be drawn aligned top center to the reference points on the x-axis. The badly rendered example image looks like single characters are placed at fixed positions out of context. Of course, this will lead to problems not only when the fonts are substituted, but also for the slight differences in font sizes... Best regards, Stefan James Graham wrote: Stefan Haustein wrote: p.s.: To simplify coping with changing font sizes, it probably makes sense to add an align parameter (left|center|right top|center|baseline|bottom) to the drawString call... How does that solve the font substitution problem? This is a real problem that people actually have with exactly the use cases you propose (e.g. [1]). [1] http://golem.ph.utexas.edu/~distler/blog/archives/000888.html
Re: [whatwg] Canvas lack of drawString method
Charles Iliya Krempeaux wrote: Hello Stefan, You'll probably need alot of info, about the font, to be able to really handle fonts properly. It's been a while since I've really written that kind of code. But just consider the concept of kerning. Any API would need to expose that kind of info too. Hi Charles, that's why I have included Font.stringWidth() in the list of Font methods (and not charWidth()) The proposed methods should be sufficient for basic needs, in particular to cope with scaling issues and to implement a word wrap algorithm. Best regards, Stefan See ya On 10/17/06, *Stefan Haustein* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont (String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight (); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca http://reptile.ca supercanadian @ gmail.com http://gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/
Re: [whatwg] Canvas 2d methods
Hi,
I would like to second the request for returning the context in drawing
methods that currently return null.
I think the following example illustrates why with is considered harmful:
var lineWidth = 10;
var lineHeight = 20;
with(ctx){
fillRect(0, 0, lineWidth, lineHeight);
}
Best regards,
Stefan Haustein
Andrew Fedoniouk wrote:
- Original Message - From: Ian Hickson [EMAIL PROTECTED]
To: Andrew Fedoniouk [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Benjamin Joffe [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Sunday, July 02, 2006 2:18 PM
Subject: Re: [whatwg] Canvas 2d methods
On Sun, 2 Jul 2006, Andrew Fedoniouk wrote:
1) if it is declared as
var foo = something; in current frame then
foo.bar();
foo.baz();
then execution is quite efficient.
But
with(something)
{
bar();
baz();
}
still requires scan of the whole universe in the worst case.
But this isn't the worst case! It's the best case -- you know exactly
what
a 2D context's members are.
Consider this:
with(ctx)
{
bar( some_var_name );
}
runtime will scan full chain of ctx for some_var_name. What for?
It will scan *exactly* the same places as it would have if you didn't
have
the with, plus the context itself.
And that ctx is pretty heavy thing.
Again, with was considered harmful - that was the inital idea of
discussion.
Anyway, this is all a straw man -- this isn't the reason that the spec
doesn't allow this. It doesn't allow this because Safari didn't do it
this
way in the first place, and changing it would likely introduce bugs
(while
still not helping authors for some time anyway).
As far as I can see return value is not defined at all in:
http://developer.apple.com/documentation/AppleApplications/Reference/SafariJSRef/Classes/Canvas.html#//apple_ref/js/Canvas.lineTo
So the proposal is just to define them as returning 'this' instead of
nothing.
Andrew Fedoniouk.
http://terrainformatioca.com
