You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Cameron McCormack <ca...@aka.mcc.id.au> on 2005/09/26 01:18:51 UTC
Implementing 'background-fill'
Hi Thomas.
I want to implement the 'background-fill' and 'background-fill-opacity'
1.2 properties. I've got it working nicely for the case when the svg
element it applies to has overflow="hidden", but the overflow="visible"
case is causing me problems.
I've modified the CanvasGraphicsNode's getPrimitiveBounds and
primitivePaint methods to handle filling the created viewport with the
background colour. When overflow="visible", though, the area to fill is
effectively infinite (subject to clipping). I've tried two ways to
handle it:
1. Have getPrimitiveBounds return an infinite area, with
new Rectangle2D.Float
(Float.NEGATIVE_INFINITY, Float.NEGATIVE_INFINITY,
Float.POSITIVE_INFINITY, Float.POSITIVE_INFINITY))
but this seems to cause problems with some calculations in the
renderer. I guess this would also be problematic if the node was
being rendered into an offscreen buffer first?
2. Have primitivePaint get the dimensions of the Graphics2D it is
painting to, transform that to the current coordinate system and
then fill that rectangle. This would be good, but
getPrimitiveBounds doesn't have access to a Graphics2D (I suppose
since it is meant to have some intrinsic dimensions irrespective of
where it will be drawn to).
And another one I've though of but haven't tried yet:
3. Have the SVGSVGElementBridge look up the current dimensions of the
root svg element and its viewing transform to compute the box that
will cover the whole viewable canvas. However, then the CGN would
have to be updated/recreated whenever the canvas is panned.
Any other thoughts on how to achieve this?
Thanks,
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Implementing 'background-fill'
Posted by Thomas DeWeese <Th...@Kodak.com>.
> Thomas DeWeese:
>>http://www.w3.org/TR/SVGMobile12/painting.html#viewport-fill-property
>>
>> This would (I think) only fill the x/y/width/height of the element.
Cameron McCormack wrote:
> I only assumed that the overflow="visible" would apply because that
> would make the (probably most common) use case of having a non-white
> background colour for the root svg element easy to do without a finite
> big rect.
The root SVG element is a bit different since the viewport for that
is defined by the User Agent (and the X,Y are ignored and width & height
are just 'hints' to the UA). So if it fills the viewport then it will
fill the 'window', even if pAR and viewBox would leave some of the
viewport area unfilled.
> The text in section 7.10 supports your position though.
>
> Though I guess for 1.2 Tiny there can only ever be one svg element in
> the document anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Implementing 'background-fill'
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> Hmm, I'm looking at the latest mobile draft and they don't
> seem to have a 'background-fill' they have a 'viewport-fill':
I was looking at the (old) 1.2 Full draft. I guess they have been
renamed.
> http://www.w3.org/TR/SVGMobile12/painting.html#viewport-fill-property
>
> This would (I think) only fill the x/y/width/height of the element.
I only assumed that the overflow="visible" would apply because that
would make the (probably most common) use case of having a non-white
background colour for the root svg element easy to do without a finite
big rect.
The text in section 7.10 supports your position though.
Though I guess for 1.2 Tiny there can only ever be one svg element in
the document anyway.
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Implementing 'background-fill'
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Cameron,
Cameron McCormack wrote:
>> The way I would implement background-fill
>>would be in the various renderers. The JSVGCanvas
>>already has a method to set the background color
>>(Through swing's setBackground() method). The
>>transcoders have 'KEY_BACKGROUND_COLOR' which
>>could use the background from the outermost
>>SVG element. So I would modify these to look for
>>the property or get the 'backgroundColor' value from
>>the RootGraphicsNode and use it when another default
>>has not been given.
>
> I think that's ok for the root svg element, but since every
> viewport-opening element can have a background-fill it needs to be drawn
> during rendering. For example:
Hmm, I'm looking at the latest mobile draft and they don't
seem to have a 'background-fill' they have a 'viewport-fill':
http://www.w3.org/TR/SVGMobile12/painting.html#viewport-fill-property
This would (I think) only fill the x/y/width/height of the element.
> <svg version="1.2" width="400" height="400">
> <svg x="100" y="100" width="200" height="200"
> background-fill="blue"/>
> <svg x="10" y="10" width="10" height="10"
> background-fill="red" background-fill-opacity="0.5"
> overflow="visible"/>
> </svg>
>
> The svg element with the translucent red background should cover the
> whole canvas, blending with the smaller blue backgrounded svg.
Bah, that would be really annoying, I hope that isn't the case...
>> Otherwise, you are correct that there is no real
>>way to have this work given the infinite canvas
>>(you can do some things like check the clip on
>>the Graphics2D and fill that region, but AFAIK
>>there is no requirement that there be a clip, so
>>what do you fill in that case? ;)
>
>
> Well, just the area visible in JSVGCanvas or transcoded image I guess.
>
> I am not very familiar with how the renderer works. Would updating the
> CanvasGraphicsNode to have a new primitive bounds whenever the document
> is panned (as in option 3) be reasonable? Does it matter that
> getPrimitiveBounds would return an area smaller than the conceptual area
> that would be filled (returning the visible canvas size (clipped)
> instead of infinite)? Does off screen compositing have any extra
> considerations?
>
> Thanks,
>
> Cameron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Implementing 'background-fill'
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Thomas DeWeese:
> The way I would implement background-fill
> would be in the various renderers. The JSVGCanvas
> already has a method to set the background color
> (Through swing's setBackground() method). The
> transcoders have 'KEY_BACKGROUND_COLOR' which
> could use the background from the outermost
> SVG element. So I would modify these to look for
> the property or get the 'backgroundColor' value from
> the RootGraphicsNode and use it when another default
> has not been given.
I think that's ok for the root svg element, but since every
viewport-opening element can have a background-fill it needs to be drawn
during rendering. For example:
<svg version="1.2" width="400" height="400">
<svg x="100" y="100" width="200" height="200"
background-fill="blue"/>
<svg x="10" y="10" width="10" height="10"
background-fill="red" background-fill-opacity="0.5"
overflow="visible"/>
</svg>
The svg element with the translucent red background should cover the
whole canvas, blending with the smaller blue backgrounded svg.
> Otherwise, you are correct that there is no real
> way to have this work given the infinite canvas
> (you can do some things like check the clip on
> the Graphics2D and fill that region, but AFAIK
> there is no requirement that there be a clip, so
> what do you fill in that case? ;)
Well, just the area visible in JSVGCanvas or transcoded image I guess.
I am not very familiar with how the renderer works. Would updating the
CanvasGraphicsNode to have a new primitive bounds whenever the document
is panned (as in option 3) be reasonable? Does it matter that
getPrimitiveBounds would return an area smaller than the conceptual area
that would be filled (returning the visible canvas size (clipped)
instead of infinite)? Does off screen compositing have any extra
considerations?
Thanks,
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Implementing 'background-fill'
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Cameron,
The way I would implement background-fill
would be in the various renderers. The JSVGCanvas
already has a method to set the background color
(Through swing's setBackground() method). The
transcoders have 'KEY_BACKGROUND_COLOR' which
could use the background from the outermost
SVG element. So I would modify these to look for
the property or get the 'backgroundColor' value from
the RootGraphicsNode and use it when another default
has not been given.
Otherwise, you are correct that there is no real
way to have this work given the infinite canvas
(you can do some things like check the clip on
the Graphics2D and fill that region, but AFAIK
there is no requirement that there be a clip, so
what do you fill in that case? ;)
Cameron McCormack wrote:
> Hi Thomas.
>
> I want to implement the 'background-fill' and 'background-fill-opacity'
> 1.2 properties. I've got it working nicely for the case when the svg
> element it applies to has overflow="hidden", but the overflow="visible"
> case is causing me problems.
>
> I've modified the CanvasGraphicsNode's getPrimitiveBounds and
> primitivePaint methods to handle filling the created viewport with the
> background colour. When overflow="visible", though, the area to fill is
> effectively infinite (subject to clipping). I've tried two ways to
> handle it:
>
> 1. Have getPrimitiveBounds return an infinite area, with
>
> new Rectangle2D.Float
> (Float.NEGATIVE_INFINITY, Float.NEGATIVE_INFINITY,
> Float.POSITIVE_INFINITY, Float.POSITIVE_INFINITY))
>
> but this seems to cause problems with some calculations in the
> renderer. I guess this would also be problematic if the node was
> being rendered into an offscreen buffer first?
>
> 2. Have primitivePaint get the dimensions of the Graphics2D it is
> painting to, transform that to the current coordinate system and
> then fill that rectangle. This would be good, but
> getPrimitiveBounds doesn't have access to a Graphics2D (I suppose
> since it is meant to have some intrinsic dimensions irrespective of
> where it will be drawn to).
>
> And another one I've though of but haven't tried yet:
>
> 3. Have the SVGSVGElementBridge look up the current dimensions of the
> root svg element and its viewing transform to compute the box that
> will cover the whole viewable canvas. However, then the CGN would
> have to be updated/recreated whenever the canvas is panned.
>
> Any other thoughts on how to achieve this?
>
> Thanks,
>
> Cameron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org