Fake Lighting Without Filters in SVG

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:

  1. I don't want the effect to depend on the colours of the underlying shape.
  2. I want to end up with something that works for as wide a range of shapes as possible.
  3. I want to be able to adjust the intensity and position of my fake light at least a little bit and with out too much work.
I've already done some of this, so I know I'll be at least partly successful (and it explains my mixed tense). Let's start with a simple circle.

More About SVG Open

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.

SVG and the Future of the GUI

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.

Catching Up - Full Test Results from Deer Park Alpha 1

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.

Standards Up Front for SVG

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 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 ;-) .

Deer Park Alpha Test Suite Results

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.
Benchmarking SVG in Browsers Today

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.

Firefox Extension for Turning Built-in SVG on and off

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.

What’s Great About Firefox Deer Park and How to Turn it Off

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 ...

Adobe buys Macromedia - what does it mean for SVG?

SVG Basics is now more Mozilla-friendly. I'm not making a big deal of it on that site yet because I still have to do more testing and see which sample code actually works well and what doesn't. For now though, surfers should at least be able to see the examples. I'll be testing with the SVG-enabled Firefox build any day now.

Syndicate content