Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of oleg.v.khaschansky@gmail.com
 designates 64.233.184.238 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Kud/VHJFa/zCstOZuAHdBh6+rBfc93xkgyZZld9BnwkMGobeY3g5GYcZVqLuNW99E8dNAehdL4fi16q1B5O0magoWZcxwz6/YL2SVrxMohvL7Aw4xQy2/wRp0kHk2Znk7MQ3C8Ah7kdiEGegjQMRPO1TLpW6A7ja10YKTyKSl18=
Message-ID: <26c14c2a0612130740w6f2f086eie6fa0185b041c9e9@mail.gmail.com>
Date: Wed, 13 Dec 2006 18:40:29 +0300
From: "Oleg Khaschansky" <oleg.v.khaschansky@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][awt] clipping area
In-Reply-To: <2A786EB15713B544AB79607529273B0432CBDB@mssmsx411>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2A786EB15713B544AB79607529273B0432CBDB@mssmsx411>

Hmm, I don't think that things are so simple. Everyone can implement
their own Shape and MultiRectArea is simply a Shape implementation. So
the testcase with it is pretty legal, why not?

But we know that RI demonstrates a different behavior if we pass the
same clip rect as a Rectangle and as a MultiRectArea. Taking this into
account I'd say that RI behavior is inconsistent.

On the other hand, we don't have pixel-by-pixel compatibility with RI
in java2d, e.g. I think, we use different shape rasterization
algorythms.

I'd suggest to close this bug as a non-bug difference.

On 12/13/06, Shipilov, Alexander D <alexander.d.shipilov@intel.com> wrote:
> >Why do you need Area here? You can use Rectangle alone.
> Yes I can. I can also use setClip without even Rectangle:
> setClip(10, 10, 2, 10);
> But I did it for 1:1 correspondence with original test :)
>
> Thanks,
> Alexander Shipilov
>
> >-----Original Message-----
> >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> >Sent: Wednesday, December 13, 2006 5:05 PM
> >To: dev@harmony.apache.org
> >Subject: Re: [classlib][awt] clipping area
> >
> >2006/12/13, Shipilov, Alexander D <alexander.d.shipilov@intel.com>:
> >> >I think that it is better to use java.awt.Rectangle here.
> >> >Please add your modified test case with the results to JIRA.
> >> Sure, it is :). I meant that I used it both:
> >>        Area area = new Area(new Rectangle(10, 10, 2, 10));
> >Why do you need Area here? You can use Rectangle alone.
> >
> >SY, Alexey
> >
> >> >-----Original Message-----
> >> >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> >> >Sent: Wednesday, December 13, 2006 4:57 PM
> >> >To: dev@harmony.apache.org
> >> >Subject: Re: [classlib][awt] clipping area
> >> >
> >> >2006/12/13, Shipilov, Alexander D <alexander.d.shipilov@intel.com>:
> >> >> Thank you, it is very appropriate action!
> >> >> So, if we change MultiRectArea for a class Area from public API,
> >> Harmony
> >> >> works the same as RI.
> >> >I think that it is better to use java.awt.Rectangle here.
> >> >Please add your modified testcase with the results to JIRA.
> >> >
> >> >> Is that means that bug
> >> http://issues.apache.org/jira/browse/HARMONY-2032
> >> >> is incorrect and we should close it?
> >> >If it is not reproducible with public API this bug is incorrect,
> IMHO.
> >> >
> >> >SY, Alexey
> >> >
> >> >> >-----Original Message-----
> >> >> >From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
> >> >> >Sent: Wednesday, December 13, 2006 4:13 PM
> >> >> >To: dev@harmony.apache.org
> >> >> >Subject: Re: [classlib][awt] clipping area
> >> >> >
> >> >> >Test case from this issue uses Harmony specific class
> >> >> >org.apache.harmony.awt.gl.MultiRectArea. I'm not sure how it was
> >> >> >integrated to RI and does it work ok on RI.
> >> >> >
> >> >> >I think that first of all this test should be modified to use
> only
> >> >> public
> >> >> >API.
> >> >> >
> >> >> >SY, Alexey
> >> >>
> >>
>