- From: Gillette Christophe-W20796 <christophe.gillette@motorola.com>
- Date: Mon, 05 Apr 2004 11:11:08 -0700
- To: www-svg@w3.org
Hi WG, <http://www.w3.org/Mail/> According to the last SVGT draft, the stroke opacity is supported in 1.2. Considering the limitations that Tiny implementations usually face, it is adequate to think that a certain number of viewers will opt for drawing the polygon segment by segment. Applying stroke opacity then becomes a problem as soon as segments overlap (joints) as the opacity is applied twice on a same pixel. It is agreed that a quick fix would be to use a buffer to draw the stroke. Some other implementations may represent the stroke with a large polygon, which fixes the issues of the joints. However, what happens with a dashed stroke? Should the implementation consider the full stroke as one polygon to avoid applying twice the opacity on overlaping pixels? If so, the memory usage is not negligeable. If not, it will have to draw into a double buffer so the joints of dashed line get drawn with the proper color. In conclusion, adding this feature will require a large usage of memory for any implementation and will break what I thought was a rule: "No double buffering in Tiny" (as in "Keep Tiny as Tiny and not an evolution towards basic"). This e-mail is just to make sure that the WG understands the burdon this feature adds on implementations vs the gain in functionality for content developers. Cheers, Christophe Gillette
Received on Monday, 5 April 2004 14:26:50 UTC