Background color for SVG

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Background color for SVG

Peter Weilbacher
I wonder if it is possible to access the background color at the place
of a SVG graphic in nsSVGCairoCanvas.cpp.
The reason behind this is that due to the way the display APIs under
OS/2 work I need to "clear" the area that is going to be used for the
SVG display. Currently, I just fill it with white, but using the
background color of the <svg> (or the browser default if none is set)
would be nicer. For now I do this (snipped from the end of
nsSVGCairoCanvas::Init):

     // clip to dirtyRect
     cairo_new_path(mCR);
     cairo_rectangle(mCR,
                     dirtyRect.x, dirtyRect.y, dirtyRect.width, dirtyRect.height);
     cairo_clip(mCR);
     cairo_new_path(mCR);
   #ifdef XP_OS2
     cairo_set_source_rgb(mCR, 1, 1, 1);
     cairo_rectangle(mCR, dirtyRect.x, dirtyRect.y, dirtyRect.width, dirtyRect.height);
     cairo_fill(mCR);
   #endif
   
     return NS_OK;

We still hope that there is a way to solve this problem inside the cairo
port but for now this is the best bet...
--
Greetings,                                                             ^
   Peter.

_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Background color for SVG

Ian Hickson
On Mon, 21 Nov 2005, Peter Weilbacher wrote:
>
> I wonder if it is possible to access the background color at the place
> of a SVG graphic in nsSVGCairoCanvas.cpp.
> The reason behind this is that due to the way the display APIs under
> OS/2 work I need to "clear" the area that is going to be used for the
> SVG display. Currently, I just fill it with white, but using the
> background color of the <svg> (or the browser default if none is set)
> would be nicer.

Isn't the SVG supposed to overlay whatever is behind it? e.g. SVG on top
of HTML would overlay that HTML?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Background color for SVG

Tim Rowley-2
In reply to this post by Peter Weilbacher
On 11/21/05 4:47 PM, Peter Weilbacher wrote:

> On Mon, 21 Nov 2005 19:53:13 UTC, Ian Hickson wrote:
>
>
>>On Mon, 21 Nov 2005, Peter Weilbacher wrote:
>>
>>>I wonder if it is possible to access the background color at the place
>>>of a SVG graphic in nsSVGCairoCanvas.cpp.
>>>The reason behind this is that due to the way the display APIs under
>>>OS/2 work I need to "clear" the area that is going to be used for the
>>>SVG display. Currently, I just fill it with white, but using the
>>>background color of the <svg> (or the browser default if none is set)
>>>would be nicer.
>>
>>Isn't the SVG supposed to overlay whatever is behind it? e.g. SVG on top
>>of HTML would overlay that HTML?
>
> I don't know what it should do but if there are transparent parts in the
> SVG it displays with the default browser background (white in most
> cases, light grey on my setup) on SeaMonkey (with cairo) under Linux. I
> thought that was what it was supposed to do. Examples of this are
>    http://www.croczilla.com/svg/samples/linestroke/linestroke.xml
> and
>    http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml

nsSVGOuterSVGFrame tells gecko that it doesn't draw a background, so we
end up just compositing atop what lies beneath us.  SVG 1.1 doesn't have
an idea of a background color - that's a proposed 1.2 feature.

If the os/2 cairo backend doesn't properly implement
_aquire_dest_surface, you might want to use the image backend (see the
printing path on the branch, or the MOZ_ENABLE_{QUARTZ,WIN32}_SURFACE
defines in nsSVGCairoCanvas.cpp on the trunk.

-tor
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Background color for SVG

Tim Rowley-2
On 11/22/05 5:20 AM, Peter Weilbacher wrote:
> The compositing is the problem on OS/2. AFAIU it's not possible to draw
> directly to the screen in an efficient way. Instead we draw to an
> offscreen surface and then blit that to the screen. To composite implies
> that we know the background color while painting the offscreen surface.

On all platforms gecko uses doublebuffering, rendering offscreen and
only showing the user the completed rendered area.  If your os/2 cairo
backend is working correctly then the composite "just happens" from the
mozilla SVG point of view.

> Let me take a look at nsSVGOuterSVGFrame, but I guess for now I just
> query the prefs for the background color and use that to fill the cairo
> surface.

That's not really a route you want to go down, as it violates the
specification and means that on os/2 SVG will act differently to all the
other platforms mozilla runs on.

> For some reason the printing path doesn't work, either. It creates the
> image surface correctly but nothing appears in the printout (or on the
> screen if I try to use that for screen display). This is probably
> connected to the offscreen surface stuff, too. I have to debug that at
> some point.

Does printing of RGBA images work on os/2?

-tor
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Background color for SVG

Peter Weilbacher
T Rowley wrote:

> On 11/22/05 5:20 AM, Peter Weilbacher wrote:
>> The compositing is the problem on OS/2. AFAIU it's not possible to draw
>> directly to the screen in an efficient way. Instead we draw to an
>> offscreen surface and then blit that to the screen. To composite implies
>> that we know the background color while painting the offscreen surface.
>
> On all platforms gecko uses doublebuffering, rendering offscreen and
> only showing the user the completed rendered area.  If your os/2 cairo
> backend is working correctly then the composite "just happens" from the
> mozilla SVG point of view.

The part that I didn't describe above and that you are not aware of was
that we cannot draw transparent pixels on OS/2 (the graphics routines
don't know an alpha channel). We can only compute the appearance of
transparency and so simulate the correct appearance.
Under these circumstances, cairo doesn't draw anything for the empty
areas. But when blitting to screen the transparent areas are filled with
whatever was there before (random parts of previous SVG content in most
cases). As cairo has no knowledge about the background color it cannot
draw these pixels correctly. Hence my original question about the
background color behind the SVG and how I could access it from
nsSVGCairoCanvas.

I am aware that when the SVG appears on top of some other content we
will get wrong results without real transparency but for now this is the
best we could do. Or did I get it all wrong again?
--
Grüße von
   Peter.
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Background color for SVG

Tim Rowley-2
On 11/23/05 3:26 AM, Peter Weilbacher wrote:

> The part that I didn't describe above and that you are not aware of was
> that we cannot draw transparent pixels on OS/2 (the graphics routines
> don't know an alpha channel). We can only compute the appearance of
> transparency and so simulate the correct appearance.
> Under these circumstances, cairo doesn't draw anything for the empty
> areas. But when blitting to screen the transparent areas are filled with
> whatever was there before (random parts of previous SVG content in most
> cases). As cairo has no knowledge about the background color it cannot
> draw these pixels correctly. Hence my original question about the
> background color behind the SVG and how I could access it from
> nsSVGCairoCanvas.

It sounds like your cairo backend might be correctly implemented, but as
it isn't in CVS I can't check.  Cairo has fallbacks that allow it to be
implemented on platforms that have no native support for an alpha
channel.  If a backend doesn't support native compositing, the fallback
calls _cairo_os2_surface_acquire_dest_image to obtain the current
surface contents, does the composite internally, and then
_cairo_os2_surface_release_dest_image to render the result.  This is
similar to the method nsImageOS2.cpp uses to draw RGBA images.

-tor
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Background color for SVG

Tim Rowley-2
On 11/24/05 3:47 AM, Peter Weilbacher wrote:
> No, from what I have heard it's not in CVS because there were some
> changes necessary to the cairo codebase to get it to compile on OS/2
> with different compilers that the cairo team didn't like. And I guess
> Mozilla syncs with cairo CVS so it's not there, either. (Hmm, can we
> check in the working OS/2 files to Mozilla CVS at all under these
> circumstances?)

The only changes we have in mozilla's copy of cairo is stuff to
integrate with our build system and vital fixes that have been merged
upstream.  The place for a new backend is in cairo's cvs.

> If you want you can take a look at the OS/2 cairo files in
>    
> ftp://ftp.netlabs.org/pub/cairo/cairo-1.0.2-2005.11.01/cairo-1.0.2-os2-s
> rc.zip
> Both functions you quote are implemented and get called when I display
> SVG content in my SeaMonkey build. But should the actual compositing be
> implemented in the backend (I notice a function
> _cairo_win32_surface_composite) or how else is cairo told that it should
> do the compositing?

While that does have a _cairo_os2_surface_acquire_dest_image, it's just
a stub and isn't reading back from the target surface as it should.

If your platform's native graphics API supports compositing, then the
backend should implement a composite function and put it in the backend
structure.  Otherwise, a null entry in the structure for composite is
what tells cairo that it needs to composite internally through the
aquire_source_image, libpixman composite, release_dest_image fallback.

-tor
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout