Re: Yet Another Theme Mockup

[Andrew Johnson <ajgenius ajgenius us>]

On Fri, 2004-09-17 at 18:17, Samuel Abels wrote:
> I've had a quick glance into the Smooth Engine source code, it may be
> possible to extend to support a Gaussian blur shadow. But my guess is
> that it is probably hard to draw that to the smooth_canvas in an
> efficient way.
> I have to look more into the source, maybe I still have an idea how to
> make this work.
> 

First off, thanks for looking at my engine, its poorly maintained these
days do to lack of time but I still have big dreams for it.

Second, the canvas is new to cvs, what is to be 0.6. The old code was
far less organized and very poorly layed out, much like the engine
specific portions of the code base still are. So you should also keep in
mind that since 0.5.8 is in gnome-themes now I decided to put off 0.6 to
coincide with the next gnome release in a few months, giving me more
time to work out some of this(hopefully), but that means making a theme
based on any features added between now and then is going to be delayed
as well simply since its not a good idea to release a theme depending on
an unreleased version. Of course that gives another 4-5 months for you
to make this mockup a reality anyway. ;)

On to specifics -

The Idea behind the canvas is to provide a common ground for engine
drawing primitives, regardless of actual backend - aka to simplify the
concept of having different drawing backends, such as cairo vs gdk2 for
when cairo reaches a point of stability in api it can be used as its own
backend(hopefully soon), and for simplifying maintenance (separating
gdk1 vs gdk2 specifics so that I don't have to worry about breaking the
mostly unmaintained gdk1 as I have in the past). This means that in
general adding new primitives is hopefully relatively easy, and so is
adding new routines and drawing types which uses it.

As to adding a Gaussian blur. I am ALL for it assuming it can be done
efficiently, which I am not completely sure of in general. I doubt it
could be added efficiently on top of the canvas like the arrow etc
routines, but its something that should be being provided by the canvas
anyway, using whatever is needed in the backend(for eg manipulating a
pixbuf directly and then rendering).

In some ways the bigger issue regarding a blur is how efficient it can
be made to be when it probably will always be being drawn on the fly,
granted with gdk2 double buffering it only is done on invalidate, but
that can be a lot still, considering large batches of repaints, such as
dragging windows etc. And you cannot easily cache images like this due
to the necessity of alpha compositing and the changing sizes of widgets.

The actual blur might be the easist thing to implement however compared
to determining when where and how to call it in the less the ideal
engine code, and how and where it should be setup as an option in the
gtkrc(another area of code that needs a complete rewrite).

Of course there is no sure way to find out how bad it will be besides
implementing it... I will look if I have time, and if you figure it out
first I am always open to patches. :)

Andrew