Re: [whatwg] '' canvas element selection buffer
Ondřej Žižka wrote:
Hi,
I've been looking for something similar to OpenGL's selection buffer - that is,
you can get some object ID for the given coordinates.
E.g., Jacob Seidelin's chess game http://blog.nihilogic.dk/search/label/chess
could use it, but instead, keyboard control had to be used.
My solution to this type of problem is to render the scene on a
(ObjectID) back buffer using a single color per object ( which serves as
ID ), and retrieve the color where the user clicked.
Simple, relatively fast and it works for any type of graphics.
It's more or less a work around but it has worked for years, on various
platforms, and is usually very fast. Plus approximate versions of the
objects can be used in the OID buffer to gain in speed and help the
user ( e.g. simplify and inflate the objects to make them easier to
point at )
isPointInPath() does not solve the problem effectively if the path would be too
complex - e.g. pixel-based sprites in several layers.
For an example of what I want to implement, see e.g.
http://www.openttd.org/screens.php?image=images/screens/0.5.0/japan_national_railway_3_aug_1984
.
Mathematical computation of the object is principially impossible (or too
complex in best case).
So, my suggestion is to add functionality similar to OpenGL's selection buffer:
The canvas element would keep a 2D array with an integer ID for each pixel.
When turned on, these values would be set by every operation that changes the
pixel, seting it to the current context's value. Pseudo-code example:
function DrawCell( iCellId ){
canvas.selectionBuffer.trackChanges( ON );
canvas.selectionBuffer.setFillValue( iCellId );
canvas.drawRasterImage( ..., cellImage );
canvas.selectionBuffer.trackChanges( OFF );
}
Then, upon user's mouse click on the canvas, you could determine which object
was clicked:
canvas.onclick = function( e ){
id = canvas.selectionBuffer.getIdAt( e.x, e.y );
// eventually:
id = e.selectionBufferID;
}
Such feature would allow interactive application with isometric or 3D graphic.
Is something like this planned or already suggested? I haven't found.
Regards,
Ondra Zizka
--
Mathieu 'p01' HENRI
JavaScript developer, Opera Software ASA
Re: [whatwg] Audio canvas?
Dr. Markus Walther wrote: I have noted an asymmetry between canvas and audio: canvas supports loading of ready-made images _and_ pixel manipulation (get/putImageData). audio supports loading of ready-made audio but _not_ sample manipulation. With browser JavaScript getting faster all the time (Squirrelfish...), audio manipulation in the browser is within reach, if supported by rich enough built-in objects. Minimally, sample-accurate methods would be needed to - get/set a sample value v at sample point t on channel c from audio - play a region from sample point t1 to sample point t2 (Currently, everything is specified using absolute time, so rounding errors might prevent sample-accurate work). More powerful methods might cut/add silence/amplify/fade portions of audio in a sample-accurate way. It would be OK if this support were somewhat restricted, e.g. only for certain uncompressed audio formats such as PCM WAVE. Question: What do people think about making audio more like canvas as sketched above? My understanding of HTMLMediaElement is that the currentTime, volume and playbackRate properties can be modified live. So in a way Audio is already like Canvas : the developer modify things on the go. There is no automated animations/transitions like in SVG for instance. Doing a cross fade in Audio is done exactly the same way as in Canvas. -- Markus -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Audio canvas?
Mathieu HENRI wrote: Dr. Markus Walther wrote: I have noted an asymmetry between canvas and audio: canvas supports loading of ready-made images _and_ pixel manipulation (get/putImageData). audio supports loading of ready-made audio but _not_ sample manipulation. With browser JavaScript getting faster all the time (Squirrelfish...), audio manipulation in the browser is within reach, if supported by rich enough built-in objects. Minimally, sample-accurate methods would be needed to - get/set a sample value v at sample point t on channel c from audio - play a region from sample point t1 to sample point t2 (Currently, everything is specified using absolute time, so rounding errors might prevent sample-accurate work). More powerful methods might cut/add silence/amplify/fade portions of audio in a sample-accurate way. It would be OK if this support were somewhat restricted, e.g. only for certain uncompressed audio formats such as PCM WAVE. Question: What do people think about making audio more like canvas as sketched above? My understanding of HTMLMediaElement is that the currentTime, volume and playbackRate properties can be modified live. So in a way Audio is already like Canvas : the developer modify things on the go. There is no automated animations/transitions like in SVG for instance. Doing a cross fade in Audio is done exactly the same way as in Canvas. And if you're thinking special effects ( e.g.: delay, chorus, flanger, pass band, ... ) remember that with Canvas, advanced effects require trickery and to composite multiple Canvas elements. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Audio canvas?
Dr. Markus Walther wrote: My understanding of HTMLMediaElement is that the currentTime, volume and playbackRate properties can be modified live. So in a way Audio is already like Canvas : the developer modify things on the go. There is no automated animations/transitions like in SVG for instance. Doing a cross fade in Audio is done exactly the same way as in Canvas. That's not what I described, however. Canvas allows access to the most primitive element with which an image is composed, the pixel. Audio does not allow access to the sample, which is the equivalent of pixel in the sound domain. That's a severe limitation. Using tricks with data URIs and a known simple audio format such as PCM WAVE is no real substitute, because JavaScript strings are immutable. It is unclear to me why content is still often seen as static by default - if desktop apps are moved to the browser, images and sound will increasingly be generated and modified on-the-fly, client-side. Agreed. Having an equivalent of the ImageData for Audio would open some really interesting possibilities. And if you're thinking special effects ( e.g.: delay, chorus, flanger, pass band, ... ) remember that with Canvas, advanced effects require trickery and to composite multiple Canvas elements. I have use cases in mind like an in-browser audio editor for music or speech applications (think 'Cooledit/Audacity in a browser'), where doing everything server-side would be prohibitive due to the amount of network traffic. Mind you I have the same use cases. --Markus -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] on ImageData, putImageData() and drawImage()
Mathieu HENRI wrote: Hi, As of today the variants of the putImageData() method copy a region of an ImageData (in device pixels) straight to a Canvas (in intrinsic pixels) and do not allow to scale the region further than the obvious device to intrinsic scaling. This means that if a developer needs to copy and scale a region of an ImageData, he needs to do so in 2 passes, and use a temporary Canvas. Also, although the the putImageData() and drawImage() methods do more or less the same thing, their arguments differ greatly. This is why, in order to allow scaling of ImageData and to simplify the blit operations, I propose to: * remove the putImageData() method and all its variants in favor of allowing the image argument of the drawImage() methods to be an instance of either an HTMLImageElement, an HTMLCanvasElement or an ImageData. * rename the remaining getImageData(sx, sy, sw, sh) method to become a new variant of the createImageData() method: createImageData(sx, sy, sw, sh) Note that if the fear of breaking existing content is too big, we could limit ourselves to just add variants of drawImage() taking an ImageData as image argument. This addition is backward compatible and should be rather trivial for implementors. These modifications would make the blit and blit-related operations of the Canvas API more simple and uniform. Kind regards, -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
[whatwg] on ImageData, putImageData() and drawImage()
Hi, As of today the variants of the putImageData() method copy a region of an ImageData (in device pixels) straight to a Canvas (in intrinsic pixels) and do not allow to scale the region further than the obvious device to intrinsic scaling. This means that if a developer needs to copy and scale a region of an ImageData, he needs to do so in 2 passes, and use a temporary Canvas. Also, although the the putImageData() and drawImage() methods do more or less the same thing, their arguments differ greatly. This is why, in order to allow scaling of ImageData and to simplify the blit operations, I propose to: * remove the putImageData() method and all its variants in favor of allowing the image argument of the drawImage() methods to be an instance of either an HTMLImageElement, an HTMLCanvasElement or an ImageData. * rename the remaining getImageData(sx, sy, sw, sh) method to become a new variant of the createImageData() method: createImageData(sx, sy, sw, sh) These modifications would make the blit and blit-related operations of the Canvas API more simple and uniform. Kind regards, -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Text APIs on canvas
Ian Hickson wrote: On Wed, 7 May 2008, Tim Johansson wrote: On Tue, 06 May 2008 05:10:41 +0200, Ian Hickson [EMAIL PROTECTED] wrote: I have introduced the following APIs: context.font context.textAlign context.textBaseline context.fillText() context.strokeText() strokeText more or less requires a scalable font, which is not available in all fonts (and frequently not in mobile phones). I cannot see any comments on what should happen when the specified font is not capable of generating a stroke. I guess doing a fill instead is the only sensible thing to do (as the author has no way of knowing which fonts are available and/or scalable and it's bad if text disappears). Stroking text is complicated as it is generally less common to have support for it in the font library. I would prefer to see stroking removed from the spec as it will not work well with all fonts/devices. The idea is that only scalable (vector) fonts should be used, since otherwise things will quickly look ugly. I've made the spec require this. Going forward the spec is likely to require effects such as adding text to paths, which will require vector data for all fonts used anyway. I don't want to mislead implementators into thinking bitmap fonts are in any way an option in this day and age. The problem is that bitmap fonts flourish on handheld and devices and, as mentioned by others, in high density alphabets. With the Text APIs being a MUST, this can be a bugger. Apropos context.fillText() and the maxWidth attribute, the spec now says 4. If the maxWidth argument was specified and the hypothetical width of the inline box in the hypothetical line box is greater than maxWidth CSS pixels, then change font to have a more condensed font (if one is available or if a reasonably readable one can be synthesised by applying a horizontal scale factor to the font) or a smaller font, and return to the previous step. Scaling the glyphs uniformly, vertically anchored to the textBaseline, would look much more coherent and be more predictable for developers than applying a non-uniform scaling or changing the font altogether. If possible I would loose the part about changing the font or applying an horizontal scale factor to the font. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Text APIs on canvas
Ian Hickson wrote: I have introduced the following APIs: context.font context.textAlign context.textBaseline context.fillText() context.strokeText() context.measureText() They are defined here: http://www.whatwg.org/specs/web-apps/current-work/#text I haven't provided a way to render text to or along a path, nor a way to do vertical text, nor a way to measure anything but the nominal layout width of text (e.g. there's no way to measure bounding boxes or get baseline metrics). I also haven't provided a way to render document fragments straight to a canvas. Here is some of the feedback on canvas related to text. I have snipped the feedback that wasn't constructive or didn't provide anything beyond requests for features without use cases and rationale, or that just bickered back and forth without making progress. If I snipped something that you think I should have responded to, please let me know. (I did take everything into account, even the bits that I haven't included below.) I haven't made many comments below, because I didn't really have much to say. There were a lot of proposals and requests, but at the end of the day there didn't seem to be strong arguments in favour of some things or other things, so I haven't tried to defend the proposed API I put in the spec relative to the other APIs that were proposed. (I did take the various proposals that were made into account, and tried to adopt the best parts of each one.) If you have further feedback, please send comments to the list, as usual. I can't see any mention that support for Text is optional. Is it reasonable with browsers approaching major releases ? The TextMetrics MUST return have 2 Float readonly properties : the width and height. The width alone is not enough. The methods fillText() and strokeText() could have a 5th optional boolean argument called wrapText ( false by default ) to specify if the text should wrap or the font-size be decrease in case the text is wider than maxWidth. It is unclear whether the transformations affect the text. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Request: Canvas Tag CSS
Thomas Broyer wrote: On Tue, Apr 8, 2008 at 11:37 AM, Greg Houston wrote: Between Anne, Thomas and I, we have clearly shown that the individual shapes within a canvas element can indeed be effected by CSS at the time of their rendering and re-rendering(such as in an animation). at the time of their rendering is the key. You cannot they are affected by CSS, it's just that your script reads the current property value from a stylesheet and uses it to draw the shapes. Affected by CSS would mean (at least that's my interpretation) reacting to CSS changes This is one of the reasons for the C in CSS. Further and/or higher changes must cascade and affect the document. (document.styleSheets[0].cssRules[0].style.color = black; or simply selecting an alternate stylesheet from your browsers view menu). Maybe you could say initialized from CSS... I have proposed a solution that greatly simplifies effecting canvas shapes with CSS. Anne and Thomas have offered two work-arounds, one of which is rather complex, and the other is a strange hack and only slightly less complex. Anne also proposed you the Simplest Thing That Could Possibly Work: use search/replace in both CSS and JS. Want to change #123456 into #567890? search #123456 and replace with #567890. I understand what you're asking for, I just don't see the need, as it seems to me it'll do more harm than good: as soon as designers will start to style your canvas using CSS, they'll start using properties that you don't support in your drawing script. I mean, as Matthieu said, canvas is imperative while CSS is declarative, so most of CSS cannot be used with canvas. The only thing you can do is read values from the CSS and use them in your canvas script. This is screaming over-engineering. There is a standard to do that, and more, already and it's called SVG. In my opinion, you'd rather have a script consisting only of variable definitions (à la *.ini or *.properties files) and have your designers only update this file (and never touch nor even see the script responsible for the actual drawing). Also, given than there are multiple ways of solving the problem (including ones allowing you to read values from CSS), I suggest pushing the debate to a later canvas version. In brief, if you really want to style diagrams using CSS, use SVG, or just don't complain that doing it with canvas is tricky. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Request: Canvas Tag CSS
Greg Houston wrote:
Having worked with the canvas tag quite a bit now, I've found that it
is a bit awkward that the canvas tag is not taking advantage of CSS.
If you are changing your site design, perhaps you want to change the
colors used in your line graphs as well. So you make the changes in
your CSS for the majority of your elements, which is rather painless,
and then for the canvas tag you then have to start digging through the
JavaScript to make your changes.
Say you are using the canvas tag to create buttons with a border and a
gradient. It would be nice to be able to change that gradient, and the
border size and color in the CSS. Maybe you are theming a site that is
using canvas elements. You are not comfortable with fooling with the
javascript, but if the basic shapes had CSS rules you might be a bit
more confident in making style changes.
What you want is called SVG.
Although there is some overlap, Canvas serves another purpose.
.myCanvas {
background-color: #fff;
width: 90px;
height: 30px;
}
.myButton {
fillStyle: rgba(0,255,0,1);
lineWidth: 1;
shadowColor: #000;
shadowBlur: 5;
}
.myGradient {
fillStyle: LinearGradient(0,0,0,30) ColorStop(0, '#00ABEB')
ColorStop(0.5, '#fff');
}
.myImage {
fillStyle: Pattern(/images/myimage.jpg) repeat;
}
ctx.fillStyle = 'css(myButton)';
ctx.strokeStyle = 'css(myButton)';
...
ctx.fillStyle = 'css(myGradient)';
Thanks for considering.
-Greg
--
Mathieu 'p01' HENRI
JavaScript developer, Opera Software ASA
Re: [whatwg] How to use SVG in HTML5?
Charles McCathieNevile wrote: On Thu, 24 Jan 2008 04:19:37 +1100, Mathieu HENRI [EMAIL PROTECTED] wrote: James Graham wrote: David Gerard wrote: ... I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported... Supporting img src=foo.svg is a requirement of SVG 1.1 [1] ... It is true that you can't use inline markup. As far as I know, img src=foo.svg is only supported in Opera 9.5 betas (maybe webkit nightlies, I forget). It's also bad HTML, since it lacks any kind of fallback. But you can use object data-foo.svg/object (again bad HTML, it should generally have some kind of fallback content - and a size). Unfortunately, of course, IE is still holding you back from doing it on the open web that simply :( object data=foo.svgobject data=foo.pngSmells like Lynx spirit./object/object cheers Chaals -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] How to use SVG in HTML5?
James Graham wrote: David Gerard wrote: Forgive me if this is a simple and obvious question. I note that all current browsers (except IE, of course) implement SVG rendering (to a better or worse degree). I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported, although several people have expressed an interest in changing that. However there are significant technical barriers to overcome at the syntax/parser level. Supporting img src=foo.svg is a requirement of SVG 1.1 [1] If the user agent includes an HTML or XHTML viewing capability or can apply CSS/XSL styling properties to XML documents, then a Conforming SVG Viewer *must* support resources of MIME type image/svg+xml wherever raster image external resources can be used, such as in the HTML or XHTML 'img' element and in CSS/XSL properties that can refer to raster image resources (e.g., 'background-image') [1] http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#ConformingSVGViewers -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Minor addition/rewording for canvas section
Anne van Kesteren wrote: On Sun, 13 Jan 2008 14:13:52 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: I did wonder about why other origins could read anything myself, so you're not alone -- it just seemed especially odd to allow images to be written safely but not ImageData. ImageData is always safe as you create it yourself. To clarify this very point: An ImageData is always safe because: * getImageData(...) must throw a Security Violation exception when called on a tainted Canvas. * it is created manually, and other same origin policies prevent information leak in to it. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] dashed lines in Canvas
Stefan Gössner wrote: One possible use case of canvas are technical drawings. For even extremely simple drawings - think of a circle with centerlines and a diameter dimension - dash-dotted lines are needed as well as dimension text. I would like to see both (dashed lines and text) in future canvas versions. Why not using SVG ? it has the features you want and more. It's a declarative format, which means you can import/export it into/from a graphic editor if you want. -- Stefan Goessner Garrett Smith wrote: On 5/21/07, Ian Hickson [EMAIL PROTECTED] wrote: On 5/19/07, Garrett Smith [EMAIL PROTECTED] wrote: Consider doing any diagramming. It's a necessary feature. Not really. For straight lines it's pretty trivial to do today anyway (either by drawing actual dashed lines or faking it with a pattern), and in general you can use other styles of lines instead of actual dashes. Now of course I'm not saying that this is always a good alternative, but it's not a blocker. If someone actually does this, then we might have to reconsider. http://ditchnet.org/canvasuml/ Someone actually did. I haven't tried using canvas for UML for publishing. If I want to make a diagram published, I'd use the above strategies. Trying to make UML Diagrams in the browser, current options are: 1) ASCII 2) Image 3) HTML + CSS + Images A UML widget for a bugzilla plugin could be useful, so long as it was simple and quicker to use than making ascii lines. Garrett -- Ian Hickson -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] HTMLMediaElement.volume
Maciej Stachowiak wrote: On Jun 1, 2007, at 6:03 PM, Ian Hickson wrote: On Fri, 23 Mar 2007, Anne van Kesteren wrote: Wouldn't it be better if no INDEX_SIZE_ERR was raised but instead the previous value was retained? For consistency with CanvasRenderingContext2D.globalAlpha for instance. It's not really important, but I think that some consistency between the various APIs would be nice. In general, actually, raising INDEX_SIZE_ERR is what the APIs do. So for consistency, volume is correct. globalAlpha, though, is not. What do people think? Should we change the canvas globalAlpha attribute to raise an exception for out-of-range values? Any browser vendors have an opinion? What about INDEX_RANGE_ERR ? This name is explicit, and consistent with INDEX_SIZE_ERR. In general I prefer silent failure to exceptions, since JS exceptions tend to lead to catastrophic failure of a whole script and thus tend to turn slight implementation differences (possibly misreading the spec in some cases) into serious compatibility issues. Although I also like silent failure, I tend to think it leads to more flamboyant failures of scripts. Having the spec. push exceptions will/should make for solid and error proof JavaScript code. Regards, -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] several messages
Ian Hickson wrote: On Fri, 21 Jul 2006, Henri Sivonen wrote: I gather that a normative reference to the Porter�Duff paper is needed: http://keithp.com/~keithp/porterduff/p253-porter.pdf On Mon, 24 Jul 2006, L. David Baron wrote: I've written tests for the 11 operators defined in the paper, plus a test for 'darker' that assumes Quartz's PlusDarker operator [1]: http://dbaron.org/tests/canvas/composite-operations4 It seems like 'darker' is currently not interoperable, and might be unlikely to become interoperable, due to different availability of compositing operators across platforms. (Quartz has PlusDarker. Mozilla uses the saturate operator that is provided by Cairo/libpixman (and also by XRender), which is described in [2] and [3], but seems to me to be quite different.) One solution to that problem would be to remove 'darker' from the spec rather than defining it one way or the other. Thoughts? I've referenced the paper and dropped 'darker'. Please, please, pretty please, bring 'darker' back. Rename it 'multiply' if you want, or if like me you think this name better reflects the operation previously known as 'darker'. Here is a list of use cases for 'darker', I already applied in realtime animations: 1. filtering and/or separating the channels of a canvas *very* quickly. 2. multiplying images. This can be really useful to compose/combine images. 3. burning images. To do so, copy the canvas A onto a smaller canvas B, fill B with a white rectangle of medium/high opacity if you want, then draw B on top of A in 'daker'. Tada, you just enhanced the dark areas of A and even introduced some nice color bleeding. Of couse all of this, actually ANY composite operation, can be achieved using ImageData objects ... but *MUCH* slower. On Wed, 28 Mar 2007, Philip Taylor wrote: [snip a very long and detailed discussion of the operators, with much research] Wow. Thanks! Based on David's input above and on your own advice, and on Vlad's later comments, I've simply removed 'darker' and referenced Porter-Duff for the others. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] putImageData() and getImageData()
Anne van Kesteren wrote: On Sat, 12 May 2007 17:54:25 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: These features are nice but I don't think authors will understand that imagedata.height != canvas.height (likewise for width). Authors will just make something that works in their browser and then assume it will work everywhere else. Which would horribly break. Even the more experienced canvas developers playing with these features have already made these mistakes. I'm not quite sure what a good solution to this problem would be. The best way forward would probably be to get rid of canvas device pixels and just make such a pixel map a canvas pixel. This means that getImageData() and putImageData() work similarly to toDataURL() and drawImage(). This will save JS developers some brain twisting sessions. If people really want high resolution canvas they could just make it high resolution and scale it down for display using CSS. Incidentally such an approach might get us rid of all the floats currently in the API... -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] How to improve the appearance of web pages
Gervase Markham wrote: Behnam ZWNJ Esfahbod wrote: This is SO overkill. This should be handled by the user agent. Actually some already do. Opera has done that for years, and IE7 is close but fall short by not zooming the background images. The second one is to get the web server decide which image file is better. An Apache httpd module can select the best response for a request for image the-company-logo if it knows which size is needed, and what mime-types are acceptable. My idea is to add a field to the http request header for image files, to let the server know which size the image is going to be shown, and then it decides to send the best answer. What's wrong with URL parameters? or CSS3 MEDIA QUERIES and/or CSS3 background-size ? img src=logo.jpg?width=100pxheight=100px width=100 height=100 Your server-side code could see this URL and serve an appropriate image. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
[whatwg] order of the color components in an ImageData object.
Hi, I couldn't find a mention of the order of the color components. Since this may vary across device/resolution/screen/... the user agent should deal with the pixel format in a transparent way and expose the components in a consistent order. Say R,G,B,A as it is already used in CSS and SVG. One more thing, it would be nice to allow to programmatically create an ImageData object. The width and height attribute would be mandatory at the instantiation. The data attribute would be filled with width * height * 4 zeros. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
[whatwg] clarification on createRadialGradient( x0, y0, r0, x1, y1, r1 )
Hi, The current specification of the createRadialGradient( x0, y0, r0, x1, y1, r1 ) [1] is a bit ambiguous about the colour to use in the disc defined by x0, y0, r0 when a colorStop is set for the offset 0. Should the disc be transparent black or should it be filled with the color defined for the offset 0 ? It seems more sense to fill the it with the color set at the offset 0. And if the developers want to have a 'holed' radial gradient they can easily set the first colorStop to rgba( R, G, B, 0 ) Regards, [1] http://www.whatwg.org/specs/web-apps/current-work/#createradialgradientx0 _Radial gradients are rendered such that a cone is created from the two circles_ , so that at the circumference of the starting circle the colour at offset 0 is used, that at the circumference around the ending circle the color at offset 1 is used, that the circumference of a circle drawn a certain fraction of the way along the line between the two origins with a radius the same fraction of the way between the two radii has the colour at that offset, that the end circle appear to be above the start circle when the end circle is not completely enclosed by the start circle, and that _any points not described by the gradient are a transparent black_. If a gradient has no stops defined, then the gradient is treated as a solid transparent black. Gradients are, naturally, only painted where the stroking or filling effect requires that they be drawn. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Still beating the drawString() dead horse...
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. The list goes on and on ... and HTML and CSS already cover it all. The HTMLElement.drawElement() method should be no problem to implement since userAgents already do render HTMLElements. Having it return an ImageData object will make it insanely simple to manipulate in Canvas. The text elements/contents can easily be in the fall back content of the Canvas tag thus keeping it accessible. 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. Everything (almost) is there. Let's not re-invent a square wheel. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Canvas lack of drawString method
On Wed, 18 Oct 2006 20:52:35 +0200, Gervase Markham [EMAIL PROTECTED] wrote: Alfonso Baqueiro 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've suggested this in the past as a solution to this problem: why not have a drawElement(elem) parameter? That way, you could build an accessible, readable version of the content inside the canvas tag, as alternative content, and copy labels or anything else into the canvas itself with drawElement(label). So the same content serves both as the accessible version and the used version. This would give us great flexibility, because the text you do have is controlled with all the power of the existing CSS and browser font model, obviating the need for font controls or font objects on the canvas API - which would inevitably be not as good as the CSS ones. And if browsers acquire downloadable font support, so does canvas. I would speculate wildly that it might even be easy to implement too. After all, I'm sure browsers have the ability to render the contents of a div tag to a drawing buffer... Indeed, adding a something like the toDataURL( [MIMEType] ) method on the HTMLelement object would make our life so much easier and open a whole new range of possibilities. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Canvas lack of drawString method
On Tue, 17 Oct 2006 20:16:33 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Alfonso, On 10/17/06, Alfonso Baqueiro [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? Canvas does have text capabilities for the sake of simplicity. Add drawString and then you need stringOnPath, clipping, styling of the texts, multiline strings, full support of unicode, ... and then you end up with a programmatic only version of SVG. I believe that some people's reason for not wanting to add it was because of Accessibility concerns. But if a user agent do no support Canvas, it MUST fallback to the descendant tags of the Canvas. There you have the accessibility mean. 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. It would easy to use DOM methods to grab the texts to display in the fallback content of the Canvas tag. Provided that the fallback markup is exposed to JavaScript in the user agents that support Canvas. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Canvas lack of drawString method
On Tue, 17 Oct 2006 20:32:11 +0200, Mathieu Henri [EMAIL PROTECTED] wrote: On Tue, 17 Oct 2006 20:16:33 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Alfonso, On 10/17/06, Alfonso Baqueiro [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? Canvas does have text capabilities for the sake of simplicity. Add drawString and then you need stringOnPath, clipping, styling of the texts, multiline strings, full support of unicode, ... and then you end up with a programmatic only version of SVG. I meant: Canvas does NOT have... Sorry if this lead to any confusion. Regards, -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
