|
History
| Log In
|
|
|
|
Two additional infos:
1) As per WHATWG-specification, changing the width or height of a <canvas>-Element will clear the <canvas> "Whenever the width and height attributes are set (whether to a new value or to the previous value), the bitmap and any associated contexts must be cleared back to their initial state and reinitialised with the newly specified coordinate space dimensions." (http://www.whatwg.org/specs/web-apps/current-work/#width3) This will create a significant difference between SWF- and DHTML-behaviour, so I strongly suggest adding this information into the docs! 2) "excanvas.js" must be updated, so that changing the width/height will be reflected to the underlying html-elements. The update is necessary, because it will introduce handling of the "onpropertychange"-Event. This is naturally IE only. (That was a quite annoying thing, I spend some hard time on resolving this issue, all went well on FF2, but IE6 was totally broken whenever I tried to change the drawview's width/height dynamically.) Sorry, I should have replied. This is partially fixed as of r5422. Rather than supporting dynamic width/height adjustment, drawview now waits for a width and height to be set before construction. This takes care of the common case where you want to constrain the height/width but it doesn't handle changing it thereafter. I'm mixed about doing this, because as you say 'This will create a significant difference between SWF- and DHTML-behaviour.' We work really hard to keep behavior consistent, so this is a dealbreaker. We do capture the canvas state in the drawview, so perhaps we could copy out a bitmap, resize, and then copy the bitmap back? A bit of a hack, but it might work. I want to add bitmap operations to drawview anyway... Thoughts?
See "We do capture the canvas state in the drawview, so perhaps we could copy out a bitmap, resize, and then copy the bitmap back?"
First, we have to separate between browsers with native support for HTML-<canvas> and IE: - For IE, we just have to adjust "excanvas.js", by removing the invocation of "getContext().clearRect()". That's plain easy. (Until now, I haven't tested this!) (But an update for "excanvas.js" is needed, see my second comment on this issue.) - Native: We could use "HTMLCanvasElement#toDataURL(..)" or "CanvasRenderingContext2D#getImageData(..)" and "CanvasRenderingContext2D#putImageData(..)", BUT: - Initially, I thought of using "toDataURL(..)" and an additional HTML-<img> to store the output before changes on width/height are applied. Whenever new data would be drawn on the drawview, I'd have used "CanvasRenderingContext2D#drawImage(..)" to rewrite the old-content back on the context. But this attempt failed (at least under FF2 and Opera). Reason: "Security: To prevent information leakage, the toDataURL() and getImageData() methods should raise a security exception if the canvas has ever had an image painted on it whose origin is different from that of the script calling the method." (from: WHATWG-spec) - so I proceeded with "getImageData" and "putImageData", but it is just supported by FF2 (no Opera, don't know about Safari) and it's (damn) slow and quite memory-consuming. As an alternative, drawview could create several HTML-<img> instead of rewriting the old-content back on the context, or we use two HTML-<canvas> (a visible and an invisible one), so we can store every bitmap from "toDataURL(..)" in an array, or we redraw the whole path on the context everytime we change width/height. As soon as I have enough time, I'll upload some examples, which are based on this proposals. So you it is easier to follow my (brief) notes on this issue. (This "security"-feature is really a show-stopper, without this "information leakage prevention" resizing would be really simple!) Any thoughts on this? Thanks for all the research! I had problems with gettImageData() also. Updating excanvas.js is no problem.
We already have the entire drawing state in an internal array. We could use that to redraw automatically. I'll proceed down that path for now, until get/putImageData() are worked out. Change 20070925-maxcarlson-3 by maxcarlson@plastik on 2007-09-25 17:03:02 PDT
in /Users/maxcarlson/openlaszlo/trunk for http://svn.openlaszlo.org/openlaszlo/trunk Summary: Make drawviews resize. New Features: Bugs Fixed: Technical Reviewer: promanik QA Reviewer: andrebargull@aol.com Doc Reviewer: (pending) Documentation: Drawviews now resize when the width or height are changed. In DHTML, the drawview will be cleared so it must be redrawn whenever the oncanvas event is sent. Release Notes: Details: drawview.lzx - In _buildcanvas(), if the canvas exists it is resized and the oncontext event is sent because it will be cleared. For IE, the canvas must be completely destroyed and rebuilt. setWidth() and setHeight() call _buildcanvas() whenever a valid height and width are set. roundrect.lzx - Clear cached color state when oncontext is sent to ensure canvas state is reset properly. Tests: http://localhost:8080/trunk/lps/components/incubator/test/test-roundrectbutton.lzx?lzr=dhtml now resizes beyond 100 pixels in IE and firefox. Files: M lps/components/extensions/drawview.lzx M lps/components/incubator/roundrect.lzx Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20070925-maxcarlson-3.tar |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
P0
Changes on width/height must be propagated down to the HTML-canvas in DHTML
LPP-4001andLPP-4007!So, please give this bug a higher priority.