Hi,
> According to the FAQ, the editor of the HTML5 spec (of which canvas is
> a part) expects it to reach W3C candidate recommendation status around
> 2012, and will not be fully finalised until 2022 or later, so there's
> plenty of time to get your requests in :-)
> http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F
>
> (And anyhow, I'm sure there's going to be an HTML6 proposal by then...)
Thanks for the pointer.
> That seems like a rather surprising omission (if indeed it is an
> omission) - Canvas's drawing capabilities are usually in step with
> SVG, which does have that feature. From a quick scan through the spec,
> it looks like strokeStyle set to a CanvasPattern might possibly do the
> job, although it is a bit unclear.
Hmmm, I'll look at that - thanks.
--
Richard Heyes
HTML5 graphing: RGraph (www.rgraph.net - updated 23rd May)
PHP mail: RMail (www.phpguru.org/rmail)
PHP datagrid: RGrid (www.phpguru.org/rgrid)
PHP Template: RTemplate (www.phpguru.org/rtemplate)
PHP SMTP: http://www.phpguru.org/smtp
On 31 May 2009, at 20:30, Richard Heyes wrote:
> Hi,
>
> Is it too late to suggest additions to the canvas spec? And if not
> does any one know who the best person to suggest them to is?
>
That would be the WHATWG mailing list:
http://www.whatwg.org/mailing-list#specs
According to the FAQ, the editor of the HTML5 spec (of which canvas is
a part) expects it to reach W3C candidate recommendation status around
2012, and will not be fully finalised until 2022 or later, so there's
plenty of time to get your requests in :-)
http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F
(And anyhow, I'm sure there's going to be an HTML6 proposal by then...)
> Like
> others I think I would find being able to specify the line style
> rather useful. Eg:
>
> context.lineStyle = 'solid'; // Default
> context.lineStyle = 'dotted';
> context.lineStyle = 'dashed';
>
That seems like a rather surprising omission (if indeed it is an
omission) - Canvas's drawing capabilities are usually in step with
SVG, which does have that feature. From a quick scan through the spec,
it looks like strokeStyle set to a CanvasPattern might possibly do the
job, although it is a bit unclear.
- Matt
Hi,
Is it too late to suggest additions to the canvas spec? And if not
does any one know who the best person to suggest them to is? Like
others I think I would find being able to specify the line style
rather useful. Eg:
context.lineStyle = 'solid'; // Default
context.lineStyle = 'dotted';
context.lineStyle = 'dashed';
Cheers.
--
Richard Heyes
Hi,
http://www.phpguru.org/dev/CanvasWars/game.html
Dunno what the hell to do with it though, At the moment it's a "dodge
the clouds" type thing... :-)
--
Richard Heyes
HTML5 graphing: RGraph (www.rgraph.net)
PHP mail: RMail (www.phpguru.org/rmail)
PHP datagrid: RGrid (www.phpguru.org/rgrid)
PHP Template: RTemplate (www.phpguru.org/rtemplate)
Hi,
Haven't done any showing off recently, so here's a dollop:
http://www.phpguru.org/article/a-html5-canvas-clock
Very similar to the example I would imagine you've already seen,
albeit with numbers. Because it uses the text and shadow APIs, it
needs Firefox 3.1b2, Chrome 2b, or Safari 4b or higher.
--
Richard Heyes
HTML5 Canvas graphing for Firefox, Chrome, Opera and Safari:
http://www.rgraph.net (Updated April 11th)
Hi,
Does anyone know if there's an ftell()-like function in the canvas
API? Situation is that I want to draw an arc from the end point of a
previous arc, but can't because I don't know the end point coords of
the first arc to pass to the second.
Thanks.
--
Richard Heyes
HTML5 Canvas graphing for Firefox, Chrome, Opera and Safari:
http://www.rgraph.org (Updated January 31st)
Note that I have only tested in FireFox and WebKit. WebKit actually shows a minor issue that's not a problem for the purposes of the POC. You can read a full errata and description of the POC here:
Let me know if you guys have any questions or concerns.
Thanks!
Jerason
On Tue, Jan 6, 2009 at 11:19 AM, Jerason Banes <jbanes@...> wrote:
Hi all!
As many of you probably noticed from my recent message, I've managed to complete a very sophisticated Javascript game recently. In addition, I've been porting several older DHTML games to work on modern systems and game consoles. One of the issues I've noticed is that there is no standard method of deploying Javascript games. (Or applications for that matter.)
Flash applications have the advantage of the SWF file. While SWF is in many ways a pseudo-standard, it does offer a single distribution for the entire program, its data, and the meta-data necessary for deployment. (e.g. Simple tools can automatically determine the correct size for display.) This is one of the reasons why sites like NewGrounds or Kongregate will take Flash-based games, but they usually won't bother with Javascript-based games.
I'd like to do something about this. Is anyone here interested in working on a new standard for Javascript deployment? Ideally, something like a JAR format for Javascript that would carry all the necessary meta data for deployment along with the payload of HTML, JS, images, and sounds.
I'm already working on proof of concepts and am in talks with other JS developers about what their needs are. Does anyone here wish to join in on such discussions? The more JS programmers I can get, the merrier. Javascript has about a dozen or so ways it could integrate itself into a webpage. So I'd like to hear from all sides to ensure that all bases are covered.
Feel free to respond on this list, or you can email me directly at jbanes@....
it's a good idea, the task seems very simple now: get the ".jzip"(this ahven't anme yet, right?) file, upack it, read metaconfig and open the main document.
That's basically it! The devil is in the details, of course. What exactly will the meta-config tell the platform? Do we open the main document in an IFrame or use AJAX to make it appear inline? Should be preload images? Is there useful information we can pass in? etc.
the rest seems natural: relative paths everywhere, define all possible config options, a sample runtime able to handle that zip file and - of course - gather more people arround the idea!
Indeed! I've been looking around for a neutral ground for having discussions around such a standard. Unfortunately, I haven't been able to find any good forums yet. (If I could, we'd all probably be members already! :-P) So for the time being, I'm hosting discussions on the WiiCade forums here:
Anyone who's interested in contributing or having their voice heard is welcome to join in the discussions. I'll of course entertain discussions through email and this mailing list as well.
I'm hoping to have a simple proof of concept ready in the next day or two. That should help clarify for everyone what I'm attempting to achieve, and how the standards could be written to meet their needs.
it's a good idea, the task seems very simple now: get the ".jzip"(this ahven't anme yet, right?) file, upack it, read metaconfig and open the main document.
the rest seems natural: relative paths everywhere, define all possible config options, a sample runtime able to handle that zip file and - of course - gather more people arround the idea!
I think we're on the same wavelength here. I was also thinking something along the lines of a JAR for Javascript. Here's the RFC I posted on the WiiCade forums on that idea:
However, it's probably best to ditch the extra MANIFEST.MF and/or WEB-INF data. Those are Java-specific forms of Meta Data. I was thinking of a similar idea, but in JSON format:
The nice thing about using JSON is that it leaves the option open for client-based integration. e.g. Rather than having a JSP or PHP page write out an IFRAME or include the script, I could have a bit of AJAX code read the extracted manifest from the server and generate the correct elements to display the application.
I think we're on the same wavelength here. I was also thinking something along the lines of a JAR for Javascript. Here's the RFC I posted on the WiiCade forums on that idea:
However, it's probably best to ditch the extra MANIFEST.MF and/or WEB-INF data. Those are Java-specific forms of Meta Data. I was thinking of a similar idea, but in JSON format:
The nice thing about using JSON is that it leaves the option open for client-based integration. e.g. Rather than having a JSP or PHP page write out an IFRAME or include the script, I could have a bit of AJAX code read the extracted manifest from the server and generate the correct elements to display the application.
Thanks!
Jerason
On Tue, Jan 6, 2009 at 11:49 AM, Leonardo <sombriks@...> wrote:
starting to understand....
since the real entry point for the javascript app remains some document, that document could have standart default information block, but it does not solve the problem about package all files on a easy way.
i've suggested .war because it's just a .zip file, the java-ish info (located inside *-INF folders) can easily be ignored.
As in Java Web Application Archives? Doesn't that seem a bit heavy-weight? WAR files would have to be deployed as complete Java applications on a servlet-capable server. My concern is that this would destroy server portability, and I don't think it's a safe bet that most hosting services would be running a Java-based server.
I think we're on the same wavelength here. I was also thinking something along the lines of a JAR for Javascript. Here's the RFC I posted on the WiiCade forums on that idea:
However, it's probably best to ditch the extra MANIFEST.MF and/or WEB-INF data. Those are Java-specific forms of Meta Data. I was thinking of a similar idea, but in JSON format:
The nice thing about using JSON is that it leaves the option open for client-based integration. e.g. Rather than having a JSP or PHP page write out an IFRAME or include the script, I could have a bit of AJAX code read the extracted manifest from the server and generate the correct elements to display the application.
Thanks!
Jerason
On Tue, Jan 6, 2009 at 11:49 AM, Leonardo <sombriks@...> wrote:
starting to understand....
since the real entry point for the javascript app remains some document, that document could have standart default information block, but it does not solve the problem about package all files on a easy way.
i've suggested .war because it's just a .zip file, the java-ish info (located inside *-INF folders) can easily be ignored.
As in Java Web Application Archives? Doesn't that seem a bit heavy-weight? WAR files would have to be deployed as complete Java applications on a servlet-capable server. My concern is that this would destroy server portability, and I don't think it's a safe bet that most hosting services would be running a Java-based server.
since the real entry point for the javascript app remains some document, that document could have standart default information block, but it does not solve the problem about package all files on a easy way.
i've suggested .war because it's just a .zip file, the java-ish info (located inside *-INF folders) can easily be ignored.
As in Java Web Application Archives? Doesn't that seem a bit heavy-weight? WAR files would have to be deployed as complete Java applications on a servlet-capable server. My concern is that this would destroy server portability, and I don't think it's a safe bet that most hosting services would be running a Java-based server.
As in Java Web Application Archives? Doesn't that seem a bit heavy-weight? WAR files would have to be deployed as complete Java applications on a servlet-capable server. My concern is that this would destroy server portability, and I don't think it's a safe bet that most hosting services would be running a Java-based server.
In addition, the WAR format carries little information about the Javascript program itself. What are its dimensions? How can it be initialized? Is it possible to deploy it as a graphical widget on a page? (e.g. IFRAME in an application using the width and height meta data from a deployment standard.)
Thanks,
Jerason
On Tue, Jan 6, 2009 at 11:26 AM, Leonardo <sombriks@...> wrote:
As many of you probably noticed from my recent message, I've managed to complete a very sophisticated Javascript game recently. In addition, I've been porting several older DHTML games to work on modern systems and game consoles. One of the issues I've noticed is that there is no standard method of deploying Javascript games. (Or applications for that matter.)
As many of you probably noticed from my recent message, I've managed to complete a very sophisticated Javascript game recently. In addition, I've been porting several older DHTML games to work on modern systems and game consoles. One of the issues I've noticed is that there is no standard method of deploying Javascript games. (Or applications for that matter.)
As many of you probably noticed from my recent message, I've managed to complete a very sophisticated Javascript game recently. In addition, I've been porting several older DHTML games to work on modern systems and game consoles. One of the issues I've noticed is that there is no standard method of deploying Javascript games. (Or applications for that matter.)
Flash applications have the advantage of the SWF file. While SWF is in many ways a pseudo-standard, it does offer a single distribution for the entire program, its data, and the meta-data necessary for deployment. (e.g. Simple tools can automatically determine the correct size for display.) This is one of the reasons why sites like NewGrounds or Kongregate will take Flash-based games, but they usually won't bother with Javascript-based games.
I'd like to do something about this. Is anyone here interested in working on a new standard for Javascript deployment? Ideally, something like a JAR format for Javascript that would carry all the necessary meta data for deployment along with the payload of HTML, JS, images, and sounds.
I'm already working on proof of concepts and am in talks with other JS developers about what their needs are. Does anyone here wish to join in on such discussions? The more JS programmers I can get, the merrier. Javascript has about a dozen or so ways it could integrate itself into a webpage. So I'd like to hear from all sides to ensure that all bases are covered.
Feel free to respond on this list, or you can email me directly at jbanes@....
The game works on both the PC and the Wii. It automatically adapts the controls to match the system you're using. Here are some of my notes from development:
Because Canvas acts as a dynamic image rather than a drawing surface, a dirty-rectangle algorithm can provide better performance under certain circumstances.
Screen wipes and dissolves are easy to achieve with Canvas by making use of the clipping and globalAlpha facilities respectively. Such effects can even be performed on animated content if the before and after images are drawn together in the same frame. Since clipping can be an arbitrary shape, it's easy to do a vertical wipe, horizontal wipe, diagonal wipe, iris wipe, or other shaped effects. Depending on the circumstance, these wipes and dissolves can be a lot more pleasing than a smash cut. In addition, they can convey information about situational changes. (e.g. If you have only one Wii Remote and connect another, a dissolve is used to convey the information that the control scheme has changed. A smash cut does not make it clear that the screen has changed. If the user blinks, they may not even see the change.)
Oddly, the dissolve that's supposed to happen when the user selects "New Game" doesn't occur in Chrome. This may be an issue with Webkit's alpha compositing features. I'll have to look into this further when I get a chance and understand what's going on.
Even though I have a Java-based canvas adapter which could be finished to provide canvas support in IE, I felt it was more advantageous to simply redirect IE users to an "upgrade your web browser" page. Lack of canvas support is far from IE's only problem. Lack of basic features like DOM2 events is a royal pain, even if they can be worked around. Given that only about 35% of our visitors use IE, I felt that it was more useful to encourage upgrades to a modern browser rather than continuing to support Microsoft's out-of-date cruft.
A wonderful feature of Canvas is that the image size in CSS can be different from the image size set on the Canvas element. The browser automatically renders to the size in the canvas element, then scales the canvas frames to the size in the CSS descriptor. This basically provides a free method of scaling to any screen size. (The actual image size is 280x192 and is scaled to fill the screen on the Wii. On the PC, it's scaled to 700x480.)
While the lack of text is a pain, it was not an issue in this case. Using a bitmap font was fairly easy and gave the "classic gaming" feel that I was looking for. Had I tried to use text rendering, it's likely that scalable fonts would have provided inferior results at such a low resolution. Even if they had looked acceptable, I've often noticed that font rendering differences can create sizing issues from OS to OS.
Hope everyone finds this information interesting and useful! :)
> I just released a Canvas-based game through WiiCade.com. Thought everyone
> here might find it interesting:
> http://www.wiicade.com/gameDetail.aspx?gameID=1317
Impressive. Takes me back to my Speccy days... :-)
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated December 20th)
The game works on both the PC and the Wii. It automatically adapts the controls to match the system you're using. Here are some of my notes from development:
Because Canvas acts as a dynamic image rather than a drawing surface, a dirty-rectangle algorithm can provide better performance under certain circumstances.
Screen wipes and dissolves are easy to achieve with Canvas by making use of the clipping and globalAlpha facilities respectively. Such effects can even be performed on animated content if the before and after images are drawn together in the same frame. Since clipping can be an arbitrary shape, it's easy to do a vertical wipe, horizontal wipe, diagonal wipe, iris wipe, or other shaped effects. Depending on the circumstance, these wipes and dissolves can be a lot more pleasing than a smash cut. In addition, they can convey information about situational changes. (e.g. If you have only one Wii Remote and connect another, a dissolve is used to convey the information that the control scheme has changed. A smash cut does not make it clear that the screen has changed. If the user blinks, they may not even see the change.)
Oddly, the dissolve that's supposed to happen when the user selects "New Game" doesn't occur in Chrome. This may be an issue with Webkit's alpha compositing features. I'll have to look into this further when I get a chance and understand what's going on.
Even though I have a Java-based canvas adapter which could be finished to provide canvas support in IE, I felt it was more advantageous to simply redirect IE users to an "upgrade your web browser" page. Lack of canvas support is far from IE's only problem. Lack of basic features like DOM2 events is a royal pain, even if they can be worked around. Given that only about 35% of our visitors use IE, I felt that it was more useful to encourage upgrades to a modern browser rather than continuing to support Microsoft's out-of-date cruft.
A wonderful feature of Canvas is that the image size in CSS can be different from the image size set on the Canvas element. The browser automatically renders to the size in the canvas element, then scales the canvas frames to the size in the CSS descriptor. This basically provides a free method of scaling to any screen size. (The actual image size is 280x192 and is scaled to fill the screen on the Wii. On the PC, it's scaled to 700x480.)
While the lack of text is a pain, it was not an issue in this case. Using a bitmap font was fairly easy and gave the "classic gaming" feel that I was looking for. Had I tried to use text rendering, it's likely that scalable fonts would have provided inferior results at such a low resolution. Even if they had looked acceptable, I've often noticed that font rendering differences can create sizing issues from OS to OS.
Hope everyone finds this information interesting and useful! :)
> ...
For anyone that's interested I've now managed to get it working:
http://dev.rgraph.org I used [event].offsetX/Y for Safari, Opera, MSIE
and Chrome, and for Firefox it was indeed a case of walking up the DOM
and using the accumulated offsetLeft etc.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated December 20th)
> Happy to be of service. :-)
Hi,
Seems I spoke too soon. Sorry for the noise.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated December 5th)
On Mon, Dec 15, 2008 at 10:16 AM, Richard Heyes <richard.heyes@...> wrote:
> The Offset* APIs are based on the location relative to the parent element.
> You'll need to compute the offset by walking the DOM using "offsetParent".
> (Don't use the DOM parent or you'll get wacky results due to the way tables
> are constructed.) Add up the offsetLeft values for each offsetParent and
> you'll arrive at the true location of the Canvas.
Hi,
That's what I was afraid of. Still, I've manged to do it (!):
> The Offset* APIs are based on the location relative to the parent element.
> You'll need to compute the offset by walking the DOM using "offsetParent".
> (Don't use the DOM parent or you'll get wacky results due to the way tables
> are constructed.) Add up the offsetLeft values for each offsetParent and
> you'll arrive at the true location of the Canvas.
Hi,
That's what I was afraid of. Still, I've manged to do it (!):
http://dev.rgraph.org/
Thank you!
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated December 5th)
The Offset* APIs are based on the location relative to the parent element. You'll need to compute the offset by walking the DOM using "offsetParent". (Don't use the DOM parent or you'll get wacky results due to the way tables are constructed.) Add up the offsetLeft values for each offsetParent and you'll arrive at the true location of the Canvas.
Thanks,
Jerason
On Mon, Dec 15, 2008 at 5:00 AM, Richard Heyes <richard.heyes@...> wrote:
Hi,
I'm having severe trouble getting the mouse coords when a canvas is
colicked on AND it's nested within a table. I've setup an example to
illustrate the issue here:
The top graph is within a table, and when you click on it, it shows
you the position of the mouse pointer (which seems fine), and the
offsetLeft of the canvas, which is coming up as 1. Clearly it
shouldn't be. I need the position of the canvas on the page, or the
position of the mouse relative to the canvas. The bottom graph is not
in a table, using a DIV for positioning, and this is fine.
Thanks for any help.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari: http://www.rgraph.org (Updated December 5th)
Hi,
I'm having severe trouble getting the mouse coords when a canvas is
colicked on AND it's nested within a table. I've setup an example to
illustrate the issue here:
http://dev.rgraph.org/
The top graph is within a table, and when you click on it, it shows
you the position of the mouse pointer (which seems fine), and the
offsetLeft of the canvas, which is coming up as 1. Clearly it
shouldn't be. I need the position of the canvas on the page, or the
position of the mouse relative to the canvas. The bottom graph is not
in a table, using a DIV for positioning, and this is fine.
Thanks for any help.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated December 5th)
> Seems to work just fine in Opera 10.
Hi,
Really? I only have Opera 9.6 installed. I think I'll wait for this
then instead of hacking (or fumbling...) around. Thanks Eric and
Philip.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated December 5th)
On Fri, 05 Dec 2008 12:45:34 +0100, Richard Heyes <richard.heyes@...>
wrote:
> Hi,
>
> Has anyone had any problem with using the rotate() method in
> conjunction with Opera?
>
> Eg: http://dev.rgraph.org/trash/tradar.html
>
> Works fine in Firefox, Chrome and Safari, but not Opera. Cheers.
Seems to work just fine in Opera 10.
Cheers
/Erik
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
On Fri, Dec 5, 2008 at 11:45 AM, Richard Heyes <richard.heyes@...> wrote:
> Hi,
>
> Has anyone had any problem with using the rotate() method in
> conjunction with Opera?
>
> Eg: http://dev.rgraph.org/trash/tradar.html
>
> Works fine in Firefox, Chrome and Safari, but not Opera. Cheers.
It looks like the problem you're experiencing is that Opera applies
transforms to paths when it's stroking/filling them, not when you're
constructing the path. So "rotate(); lineTo(); stroke()" is equivalent
(in Opera, not other browsers) to "lineTo(...); rotate(...);
stroke()". That means you can't do "lineTo(); rotate(); lineTo(); ...;
stroke()", because both lines get rotated by exactly the same amount.
(Opera's behaviour used to match the HTML5 canvas specification, but
then the spec changed to match what other browsers did, and Opera
hasn't been fixed yet.)
To make it work in all browsers, you'll probably have to not use
rotate() and instead do the trigonometry manually. I think it should
work if you change the "Thi bit draws the graph" loop to something
like:
for (i in this.data) {
/* ... same as before, then: */
var angle = RGraph.degrees2Radians(360 / this.data.length) * i;
if (i == 0) {
this.context.moveTo(xPos*Math.cos(angle), xPos*Math.sin(angle));
} else {
this.context.lineTo(xPos*Math.cos(angle), xPos*Math.sin(angle));
}
}
--
Philip Taylor
excors@...
Hi,
Has anyone had any problem with using the rotate() method in
conjunction with Opera?
Eg: http://dev.rgraph.org/trash/tradar.html
Works fine in Firefox, Chrome and Safari, but not Opera. Cheers.
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 29th)
> If I have ui elements in a canvas that I want to be clickable - what
> is the best way to go about doing that? Do I need to create some kind
> of collision detection to see if the mouse x,y is in a region? Or is
> there some better way?
You can:
1. Attach a function to the canvas onclick event
2. Get the mouse coords from the resultant event object.
3. Those, combined with some magic, will help you get the position of
the mouse cursor.
Below is a function which I use. If nested within a TABLE though, it
doesn't seem to work. :-( Any amount of DIV nesting does though. You
can see it in action here: http://dev.rgraph.org The top graph has
clickable bars.
http://www.phpguru.org/downloads/mousecoords.txt
--
Richard Heyes
HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 1st)
If I have ui elements in a canvas that I want to be clickable - what
is the best way to go about doing that? Do I need to create some kind
of collision detection to see if the mouse x,y is in a region? Or is
there some better way?