gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] invalidated bounds redesign - advice needed


From: strk
Subject: Re: [Gnash-dev] invalidated bounds redesign - advice needed
Date: Tue, 13 Feb 2007 16:08:33 +0100

On Tue, Feb 13, 2007 at 03:10:07PM +0100, Udo Giacomozzi wrote:
> I need some advice from you c++ gurus :-)

We miss them a lot ;)

> The new design should allow multiple rects in one class and
> automatically combine them when it's appropriate. That is, when rects
> intersect each other or come close by very few pixels.
> 
> What is the most efficient / elegant design for such a class? Remember
> that the class will be very busy comparing and combining rects.

Eh, hard to tell. Using some spatial indexing is likely the way
to go, and there are likely libraries out there for that.
Boost itself might provide something. I don't feel like proposing
GEOS as I know it way too much performance-wise.
I'd generally leave performance consideration in a second phase
and concentrate on the interface initially.
I can imagine something along these lines:

        template <class T>
        class SnappingRanges<T> // how do you like the name ? :)
        {
        public:

                typedef Range2d<T> RangeType;

                // Add a Range to the set, merging when
                // possible and appropriate
                //
                add(const RangeType& range);

                // Substract a Range (needed? hope not!)
                substract(const RangeType& range);

                /// Visit the current Ranges set
                //
                /// Visitor instance will be invoked
                /// for each RangeType in the current set.
                ///
                template <class V> void visit(V& v) const;

        private:

                typedef std::list<RangeType> RangeList;

                // The current Ranges list
                RangeList _ranges;

        };

> I opt to let it up to the renderer how it handles these multiple
> invalidated bounds. By default render_handler_tri (all but AGG) would
> simply restart the rendering process for each clipping rectangle.

Sounds fine to me.

--strk;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]