[Qgis-developer] Moving forward with the raster transparency branch

[Marco Hugentobler]

Hi Peter,

Another comment about the refactoring of raster layer:
It would be good if thread safety could be another criterion for the raster 
redesign. That means that member variables describing the iteration state in 
providers should be separated into an iterator object. Martin and I discussed 
this for vector layers on the mailing list. As there is raster refactoring 
anyway, it would be good to consider this point as well. Hopefully, at some 
point in future, qgis may benefit from the capabilities of multicore cpus.

Regards,
Marco

On Tuesday 11 September 2007 16:47:42 Peter Ersts wrote:
> QGIS Devs,
>
> There has been interest in merging the mods in the
> raster_transparency_branch into the 0.9.1 release. The main changes
> currently are:
> 1) Revival of basic contrast enhancement
> 2) Introduction of transparent pixel lists
> 3) Foundation for basic color ramps.
>
> More information about the raster_transparency_branch can be found here:
>
> http://wiki.qgis.org/qgiswiki/RasterTransparencyBranch
>
> Back in May and June there was a meeting to discuss refactoring of the
> monolithic (5K+ lines) QgsRasterLayer class. The last UML design can be
> found here:
>
> http://wiki.qgis.org/qgiswiki/RasterRefactorRfc
>
> There still needs to be some discussion regarding the final refactoring
> of QgsRasterLayer as there are some great ideas being proposed but
> uncertainty regarding the best approach.
>
> In the mean time, I am proposing that contract enhancement and
> transparency be the first functionality that is broken out of
> QgsRasterLayer, as they are relatively well defined, discrete components
> that are well suited for being separate classes. I will undertake this
> in the current raster_transparency_branch with the goal of having this
> ready for the 0.9.1 release. I propose that classes be named:
>
> QgsRasterTransparencyFilter
> QgsRasterContrastEnhancementFilter
>
> I am not sold of the Filter suffix but am still using the June UML as a
> bit of a guide. These changes should not affect anything outside of
> QgsRasterLayer and should not adversely affect anything class that
> inherits QgsRasterLayer.
>
> Please let me know what you think.  Marco, I want to specifically ensure
> that these proposed changes will not impact anything you are currently
> working on. Again, these changes will be made under the
> raster_transparency_branch first, then at a later date merged into the
> trunk.
>
> Thanks
> -pete
>
> BTW: from the 12 to the 22 I will have limited access to e-mail, so
> apologies ahead of time if I am slow to respond .



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee
marco.hugentobler at karto.baug.ethz.ch