W3C home > Mailing lists > Public > www-svg@w3.org > April 2004

Tiny 1.2 - Stroke opacity

From: Gillette Christophe-W20796 <christophe.gillette@motorola.com>
Date: Mon, 05 Apr 2004 11:11:08 -0700
Message-ID: <4071A13C.7020002@motorola.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:27 GMT