Raster layer opacity

[Bernhard Reiter]

Am 24. Mar 2005 um 22:43:41 schrieb Jonathan Coles:
> Am Mittwoch, den 23.03.2005, 10:41 -0500 schrieb Jonathan Coles:
> > Here'a question: Is opacity a property of all layers or just raster
> > layers? perhaps we can't support opacity in vectors layers just yet, but
> > should that mean we shouldn't anticipate it? If opacity is a property of
> > all layers then I can refactor the opacity methods in RasterLayer into
> > BaseLayer.
> 
> further questions:
> 
> a) if alpha blending is not available (i.e. wxWidgets < 2.5.3) should
> the renderer fall back to using a bitmask, 

Yes. I think having at least a bitmask available is important for users.

> b) should the masking information be added to the session file? now
> there are three options for masking: none, bitmap, and alpha. alpha has
> a level setting too.

I don't really know. Probably yes, though I do not know about Thuban's 
session file design. 

> c) this is question which addresses an HCI issue. i'll give a specific
> example first, but this applies to a more general problem. i'll assume
> for the sake of argument that we decide to save the masking setting in
> the session file.
> 
> let's say that alpha blending is selected with opacity level 128. the
> session is saved. later the method is changed to use a bitmap (for
> whatever reason). the session is saved again. in the RasterLayer class,
> as it stands now, the mask type and the opacity are two independent
> settings. conceivably, the opacity level can stay in the session file
> regardless of the mask setting. the benefit would be that if the user
> decides to revert back to using alpha blending, the original opacity
> level is still available. so the question here is: is this acceptable
> behaviour?

IMO yes.

> to make this a more general question: should we save information about
> the state of an option that has used in the past, whether it is
> currently used by the active session or not, so that when/if the user
> decides to return to past settings (even across multiple sessions), they
> don't have to remember (or waste time recalculating) past values?

If we find a way of letting plugins add values to the sesssion file,
there will be the common situation that some properties will not be
understood by a current Thuban, because it lacks the plugins. In
that case the unknown values need to be preserved.

I wonder in this specific case if you should save the bitmap option
at all. Do we expect a speed gain when using bitmap instead of alpha
when alpha is available. Otherwise we might say that we do not need
the setting bitmap, as it will be automatically used if alpha is not
available to approximate what we want to render.

> i think this can be a very powerful feature if we decide that "yes" is
> the answer. although there may be some objection in that this can
> increase the size and/or complexity of the session file, please remember
> that our objective should be to make a product that improves the lives
> of the *users* not the developers (although this is a good thing too :)

Wisely spoken,
I hope that we try to make this as simple for the users as possible 
without taking control out of their hands. ;)

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20050329/d49807a8/attachment.bin