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

Re: [E-devel] xrender engine patch



On Thu, 8 Jun 2006 17:18:05 -0500 brian.mattern@gmail.com babbled:

> On Thu, Jun 08, 2006 at 06:44:20AM +0000, jose_ogp@juno.com wrote:
> >     But we have an issue to settle -- the semantics of scaling 
> > images with "borders", as you and I've been discussing :) 
> >  
> >     Namely, what exactly does this mean? 
> >  
> >     Here's a question for everyone here on this list: 
> >  
> > 	"What is the result of scaling a *bordered-image* which 
> > has a white center and a red border?" 
> >  
> >     What should the result look like? 
> >  
> 
> Say we have an image as follows:
> 
>   +------+
>   | +--+ |
>   | |  | |
>   | |  | |
>   | +--+ |
>   +------+
> 
> where the outer part is a 5px wide red border and the inner part is
> white.
> If you set evas' image border to 5px all around, and scale up to a
> larger size, what *I* would prefer to see is simply:
> 
>   +------------------+
>   | +--------------+ |
>   | |              | |
>   | |              | |
>   | |              | |
>   | +--------------+ |
>   +------------------+
> 
> That is, keep the 4 corner regions as they are, scale the side pieces
> vertically, scale the top regions horizontally, and scale the inside as
> normal.
> 
> I haven't looked at evas' current code, but I know one thing it does
> differently from this is that the scaling takes into account the color
> of the pixels closest to the inside of the bottom and right borders
> while scaling the center. So, you actually get something like:
> 
>   +------------------+
>   | +--------------+ |
>   | |             \| |
>   | |             \| |
>   | | \ \ \ \ \ \ \| |
>   | +--------------+ |
>   +------------------+
> 
> where the \'s are a fade from red to white. I understand this is just a
> result of the algorithm used, but I'd definitely prefer to see it done
> like above. (Basically scale each of the 9 sections individually and
> stick em back together).
> 
> But, as I said, I haven't looked at the actual algorithm used currently,
> so I don't know if this would be a performance hit to get 'right'.

well the code literally does the last case - in the software engine, as that's
just what i decided policy-wise. if you don't want it - simply use an extra
row/column of pixels at the edges to stop it... :) but it IS important to be
consistent - regardless. i think it's much of a muchness tho - moving to what
you prefer won't break anything. :)

> --
> rephorm
> 
> 
> 
> 
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)