I'm going to continue from the last example I posted with the shading under the sphere. To see how I got this far, read yesterday's post: Fake Lighting Without Filters in SVG. Dark is the opposite of light, so as a first approximation, I'll try just applying a gradient that's conceptually opposite to the one I made for the light effect. The size of the shading gradient will be the same as the light, but it will be black instead of white. The focal point will also be moved; to the exact opposite side. So the (fx,fy) of (70%,15%) maps to (30%,85%).
I've been doing some playing around with SVG effects that can be achieved without filters. I started playing because the build of Firefox (Deer Park Alpha 2) that I'm using doesn't have them built-in. There's work under way and a patch is available if you build from source.
There are better reasons for faking lighting though. Filters are resource intensive and sometimes you don't care about realistic lighting so much as just a way to make something shiny (or shadowed). The comparable filter to what I'm talking about today is fePointLight.
My simple example is lighting a circle to make it look more like a sphere. I have a few goals:
Looks like there's a whole lot more info at the SVG Open site. I was just looking over the schedule, lamenting that it's too far away from me this year, and I see there are links for some of the content that's being presented. I'll be looking over the SVG/XAML comparison presentation. The Cartoon Oriented User Interfaces presentation sounds interesting, I hope they'll post some info later.
Kurt Cagle has posted a summary of his keynote speech from SVG Open 2005. He covers a lot of ground on XML and the next generation of GUI. Pretty inspiring stuff as an SVG enthusiast. The amazing part is that even though we've all been hearing about subscribing to software since the 90's, this time I can see it coming. Not soon like next month, but soon like in a couple years.
I know Deer Park Alpha 2 is already out, but I said I'd put up the full table of my results from testing the alpha build against the SVG test suite if anyone was interested. Someone was interested, so here's the big table. Remember these are just my subjective results and for the most part I only made one pass. I also realize that many failures are because of the use of the invalid MIME-type "text/ecmascript" in the tests. I still consider those a failure - even though I realize the test is flawed. The world is a tough place.
Big ugly table after the jump.
Jeff has his results up from testing the Opera native SVG Tiny rendering on Windows XP. He also points to similar testing with different results from Antoine Quint over at SVG.org. I'd guess that maybe they're using different operating systems, otherwise I'll have to finally go get Opera and cast a tie-breaker vote ;-) .
I'd planned to put together a big table of all my test results from Firefox, and I have that. Just it's in a spreadsheet, not a web page. If anyone really wants to see that, just ask and I'll send it along. I've decided that I'd rather summarize my findings here. I think that's a lot more useful than just another table of red and green - especially since that would imply something far more official than I intend to. So today I'll talk a little about my subjective results of looking at all the tests in the SVG test suite with Firefox Deer Park Alpha 1.1. I looked at features that should be supported according to the Mozilla SVG status page and features that are clearly documented as not supported.
Why bother looking at unsupported features? Failure mode analysis. It's one thing to say that a feature is not supported and it's another to know what will happen when that feature is requested anyways. I know this is bound to change before the final release of 1.1, but alpha builds are for testing, right?Anyhow, the test suite prefixes and the modules described in the Mozilla SVG implementation status page don't clearly line up all the time, so I just made my best guess at where each test fits in terms of the primary features being tested and what Mozilla supports. The ones that should be supported are the ones I'll talk about first (and file bugs if it makes sense), the ones that shouldn't be supported I'll give some attention to another day if it's warranted.
I just got my dinner: a slice of raspberry-lemon loaf and a "grande no bovine-growth-hormone mocha" (the barrista's words, not mine). I'm settling down to try and deal with the fact that I'd better get to work on my next little project.
Maybe it's motivated by guilt from my persisent preference for the Adobe SVG viewer, but I decided to take the new Firefox Deer Park Alpha 1.1 through the W3C SVG test suite and see how it does. That way I can do what you're supposed to do with Alpha builds: find bugs and report them.
So, as I was saying yesterday, I wrote a simple Firefox extension that just turns the about:config preference for svg.enabled on or off.
Read on to download it.
I tried out the alpha build of Firefox 1.1, codenamed Deer Park. It looks pretty nice. The big deal for me is that it has built-in SVG rendering. Built-in incomplete SVG rendering.
To be frank, I've been putting off writing this post because I don't want to come off sounding negative, and I'm not sure how to approach it. I just like Adobe SVG Viewer better.
Read on, it can only get better ...