From sacadmin Thu Mar 6 12:51:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26Kp4vo005513 for ; Thu, 6 Mar 2008 12:51:05 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26KouE8001260; Fri, 7 Mar 2008 04:51:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00G19TX0QA00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 12:51:00 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00BMXTX0MV50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 12:51:00 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26Kp0n6041783; Thu, 06 Mar 2008 12:51:00 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26Kp0mc004980; Thu, 06 Mar 2008 12:51:00 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m26Kp0gI004979; Thu, 06 Mar 2008 12:51:00 -0800 (PST) Date: Thu, 06 Mar 2008 12:50:59 -0800 From: Danek Duvall Subject: mediaLib argument ambiguity clarification [LSARC/2008/182 FastTrack timeout 03/12/2008] In-reply-to: <47D05435.9050604@Sun.COM> To: James Cheng Cc: lsarc@sun.com, viseng@sun.com Message-id: <20080306205059.GL9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> <47CFAFE3.7010402@sun.com> <20080306182509.GH9130@zruty.sfbay.sun.com> <47D0407B.1040809@Sun.COM> <20080306191258.GI9130@zruty.sfbay.sun.com> <47D04650.4020703@sun.com> <47D05435.9050604@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 3627 I've filed this case as LSARC/2008/182. Timeout is next Wednesday. Release binding is Minor. I'm going to move the previous mails in this thread to the mail log for this case. Danek On Thu, Mar 06, 2008 at 12:29:41PM -0800, James Cheng wrote: > Hi Danek, > > Attached please find a list of functions affected by > this change. Please let me know if you need more info > or materials. > > Thanks, > -James > Fixing API ambiguity in some video color conversion functions > -- changing argument type from mlib_u32 * to mlib_u8 * > > 3/06/08 james.cheng@sun.com > > There are the following 41 functions in mediaLib 2.5 which have > arguments of type mlib_u32 *: > > mlib_VideoColorABGRint_to_ARGBint > mlib_VideoColorBGRAint_to_ABGRint > mlib_VideoColorBGRint_to_ABGRint > mlib_VideoColorBlendABGR > mlib_VideoColorBlendABGR_Inp > mlib_VideoColorBlendABGR_ResetAlpha > mlib_VideoColorBlendABGR_ResetAlpha_Inp > mlib_VideoColorRGBint_to_ABGRint > mlib_VideoColorRGBseq_to_ABGRint > mlib_VideoColorRGBXint_to_ABGRint > mlib_VideoColorRGBXint_to_ARGBint > mlib_VideoColorUYV444int_to_ABGRint > mlib_VideoColorUYV444int_to_ARGBint > mlib_VideoColorUYV444int_to_UYVY422int > mlib_VideoColorUYV444int_to_YUYV422int > mlib_VideoColorUYVY422int_to_ABGRint > mlib_VideoColorUYVY422int_to_ARGBint > mlib_VideoColorXRGBint_to_ABGRint > mlib_VideoColorXRGBint_to_ARGBint > mlib_VideoColorYUV411seq_to_ABGRint > mlib_VideoColorYUV411seq_to_ARGBint > mlib_VideoColorYUV411seq_to_UYVY422int > mlib_VideoColorYUV411seq_to_YUYV422int > mlib_VideoColorYUV420seq_to_ABGRint > mlib_VideoColorYUV420seq_to_ARGBint > mlib_VideoColorYUV420seq_to_UYVY422int > mlib_VideoColorYUV420seq_to_YUYV422int > mlib_VideoColorYUV422seq_to_ABGRint > mlib_VideoColorYUV422seq_to_ARGBint > mlib_VideoColorYUV422seq_to_UYVY422int > mlib_VideoColorYUV422seq_to_YUYV422int > mlib_VideoColorYUV444int_to_ABGRint > mlib_VideoColorYUV444int_to_ARGBint > mlib_VideoColorYUV444int_to_UYVY422int > mlib_VideoColorYUV444int_to_YUYV422int > mlib_VideoColorYUV444seq_to_ABGRint > mlib_VideoColorYUV444seq_to_ARGBint > mlib_VideoColorYUV444seq_to_UYVY422int > mlib_VideoColorYUV444seq_to_YUYV422int > mlib_VideoColorYUYV422int_to_ABGRint > mlib_VideoColorYUYV422int_to_ARGBint > > The functions were not specified very clearly, but they were > implemented in a way that they work identically on both SPARC > and x86. In other words, they were implemented as if those > arguments were of type mlib_u8 * and the color components (A, > R, G, B, X, Y, U, and V) were assumed to be laid out in memory > in the order as shown in the function and argument names. > > The ambiguity caused the Java wrappers of those functions, > implemented with int[] arguments, behave differently from > the pure Java implementation of those methods, where int[] > can not be cast to byte[], on x86. We could reorder bytes > in the Java wrappers on x86, but it'd make the wrappers slower > and, more importantly, the method names would not match their > behaviors on x86. > > The easiest and best way of fixing this problem appears to be > that we change those arguments from type mlib_u32 * to > mlib_u8 * with a restriction of 4-byte alignment on those > pointers. The implementation will not be changed, as the > pointers are cast to mlib_u8 * (or mlib_d64 * in case of VIS, > or __m128i * in case of SSE2, when the pointers are aligned) > already in current implementation. Therefore, the ABI will > not be changed. From owner-lsarc Wed Mar 5 19:49:17 2008 Return-Path: Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m263nGHN000535 for ; Wed, 5 Mar 2008 19:49:17 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m263mtMP027367; Thu, 6 Mar 2008 11:49:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00501IM0GR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 19:49:12 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA00BG3ILZU1A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 19:49:11 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m263nBiB031245; Wed, 05 Mar 2008 19:49:11 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m263nBL5000170; Wed, 05 Mar 2008 19:49:11 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m263nAxc000169; Wed, 05 Mar 2008 19:49:11 -0800 (PST) Date: Wed, 05 Mar 2008 19:49:10 -0800 From: Danek Duvall Subject: Re: Is this API change allowed in a minor release? In-reply-to: <47C49D50.7060909@sun.com> To: James Cheng Cc: lsarc@sun.com, "viseng@Sun.COM" Message-id: <20080306034910.GM296@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Content-Length: 946 Lines: 24 I was hoping someone more conversant with compiler issues would take this on, but since crickets have been chirping for a week ... I think it depends on: - What the declared stability of these methods is - In what versions of what products these methods shipped If they're Uncommitted and they shipped in some S10 release, then you're fine. If they've only shipped in Nevada, then you're fine. In other situations, you might not be fine. If you let us know the answers to the above two points, we can provide a bit more help. (Note that the release numbering of your project is only relevant to the question if it ships as a standalone product. I know it used to, but I can't recall if it still does today.) Even if you're "fine", you still need to release-note the change, or provide some way of notifying all your consumers. ABI compatibility is generally more important than API compatibility, if both can't be achieved. Danek From owner-lsarc Wed Mar 5 22:45:55 2008 Return-Path: Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m266jsa7004878 for ; Wed, 5 Mar 2008 22:45:54 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m266jnTg023195; Thu, 6 Mar 2008 06:45:50 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00201QSD4S00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 22:45:49 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA009YNQSCK740@nwk-avmta-1.sfbay.Sun.COM>; Wed, 05 Mar 2008 22:45:49 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m266jmqr013183; Wed, 05 Mar 2008 22:45:48 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXA00301QMK8500@fe-sfbay-10.sun.com> (original mail from James.Cheng@Sun.COM); Wed, 05 Mar 2008 22:45:48 -0800 (PST) Received: from [192.168.1.100] ([71.141.130.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXA000M7QSC8G10@fe-sfbay-10.sun.com>; Wed, 05 Mar 2008 22:45:48 -0800 (PST) Date: Wed, 05 Mar 2008 22:45:48 -0800 From: James Cheng Subject: Re: Is this API change allowed in a minor release? In-reply-to: <20080306034910.GM296@zruty.sfbay.sun.com> Sender: James.Cheng@sun.com To: Danek Duvall Cc: lsarc@sun.com, "viseng@Sun.COM" Reply-to: James.Cheng@sun.com Message-id: <47CF931C.2040602@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Content-Length: 1582 Lines: 46 Hi Danek, On 3/5/2008 7:49 PM, Danek Duvall wrote: > I was hoping someone more conversant with compiler issues would take this > on, but since crickets have been chirping for a week ... Thanks for taking my question. > > I think it depends on: > > - What the declared stability of these methods is Currently, in mediaLib 2.5, they are declared as Committed. They were changed from Evolving just before the release of mediaLib 2.5. > > - In what versions of what products these methods shipped They have been shipped in several versions of mediaLib, standalone and in Solaris. Currently, mediaLib 2.5 is in Nevada and on the web, and it will be in S10U5. S10U4 has mediaLib 2.4 which has the same problem, I think. > > If they're Uncommitted and they shipped in some S10 release, then you're > fine. If they've only shipped in Nevada, then you're fine. In other > situations, you might not be fine. If you let us know the answers to the > above two points, we can provide a bit more help. (Note that the release > numbering of your project is only relevant to the question if it ships as a > standalone product. I know it used to, but I can't recall if it still does > today.) It is still provided as a standalone product, mainly for S9 and older. > > Even if you're "fine", you still need to release-note the change, or > provide some way of notifying all your consumers. > > ABI compatibility is generally more important than API compatibility, if > both can't be achieved. Yeah, we wanted to change the API but keep the ABI compatible. Thanks, -James From owner-lsarc Wed Mar 5 23:13:08 2008 Return-Path: Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m267D8jk005320 for ; Wed, 5 Mar 2008 23:13:08 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m267D3v8040416; Thu, 6 Mar 2008 00:13:06 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00I01S1R4A00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Mar 2008 23:13:03 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA005MKS1RQIB0@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Mar 2008 23:13:03 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m267D3La033191; Wed, 05 Mar 2008 23:13:03 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m267D2N3000936; Wed, 05 Mar 2008 23:13:02 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m267D2V9000934; Wed, 05 Mar 2008 23:13:02 -0800 (PST) Date: Wed, 05 Mar 2008 23:13:02 -0800 From: Danek Duvall Subject: Re: Is this API change allowed in a minor release? In-reply-to: <47CF931C.2040602@sun.com> To: James Cheng Cc: lsarc@sun.com, "viseng@Sun.COM" Message-id: <20080306071302.GR296@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Content-Length: 516 Lines: 13 On Wed, Mar 05, 2008 at 10:45:48PM -0800, James Cheng wrote: > Yeah, we wanted to change the API but keep the ABI compatible. I think that given the exposure the functions have had, that's pretty much your only option, other than keeping it the way it is. It's not clear to me why it needs to be changed, though -- is this to make code that wants to peel apart the ARGB values in that argument simpler because it'll work identically on sparc and x86? Aren't customers dealing with this right now already? Danek From owner-lsarc Thu Mar 6 00:48:39 2008 Return-Path: Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m268mdAj008725 for ; Thu, 6 Mar 2008 00:48:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m268mbcN020296; Thu, 6 Mar 2008 00:48:37 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXA00M07WH0RC00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 00:48:36 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXA00MFZWH00O10@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 00:48:36 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m268maeM015734; Thu, 06 Mar 2008 00:48:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXA00001WCUS300@fe-sfbay-10.sun.com> (original mail from James.Cheng@Sun.COM); Thu, 06 Mar 2008 00:48:36 -0800 (PST) Received: from [192.168.1.100] ([71.141.130.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXA00EZ9WH07U40@fe-sfbay-10.sun.com>; Thu, 06 Mar 2008 00:48:36 -0800 (PST) Date: Thu, 06 Mar 2008 00:48:35 -0800 From: James Cheng Subject: Re: Is this API change allowed in a minor release? In-reply-to: <20080306071302.GR296@zruty.sfbay.sun.com> Sender: James.Cheng@sun.com To: Danek Duvall Cc: lsarc@sun.com, "viseng@Sun.COM" Reply-to: James.Cheng@sun.com Message-id: <47CFAFE3.7010402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Content-Length: 1949 Lines: 77 Danek, > It's not clear to me why it needs to be changed, though -- is this to make > code that wants to peel apart the ARGB values in that argument simpler > because it'll work identically on sparc and x86? Aren't customers dealing > with this right now already? It's mainly for removing some ambiguity in the C API and solving a problem with their Java wrappers. Let me use an example, where AA, RR, GG, and BB stand for 8-bit components, foo_good(uchar *ARGB) // works identically on sparc and x86, :-) { ARGB[0] = AA; ARGB[1] = RR; ARGB[2] = GG; ARGB[3] = BB; } foo_bad(uint *ARGB) // works differently on sparc and x86, :-( { ARBG[0] = AARRGGBB; } foo_ugly(uint *ARGB) // works identically on sparc and x86, ;-) { uchar *p = (uchar *)ARGB; p[0] = AA; p[1] = RR; p[2] = GG; p[3] = BB; } Basically we'd like to change foo_ugly to foo_good. The man pages of those functions like foo_ugly are kind of ambiguous. One might think foo_ugly would behave like foo_bad if s/he didn't see its implementation, but it actually behaves like foo_good. We could clarify this in the man pages, so no big deal. But for the Java wrappers for functions like foo_ugly, the Java wrapper looks and behaves like this on sparc: foo_ugly(int[] ARGB) { ARGB[0] = AARRGGBB; } but behaves like this on x86: foo_ugly(int[] ARGB) { ARGB[0] = BBGGRRAA; } It's ugly to see a Java method behave differently on different platforms. We could reorder bytes in the Java wrappers on x86, but it'd make the wrappers slower and, more importantly, the method names would not match their behaviors on x86, e.g., foo_ARGB would behave like foo_BGRA, and vice versa. If we could change the API to something like foo_good, then we'd remove the ambiguity in the C API and have the Java wrapper behave like this on both sparc and x86: foo_good(byte[] ARGB) { ARGB[0] = AA; ARGB[1] = RR; ARGB[2] = GG; ARGB[3] = BB; } Hope it's clearer now. Thanks, -James From owner-lsarc Thu Mar 6 10:25:18 2008 Return-Path: Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26IPITK027902 for ; Thu, 6 Mar 2008 10:25:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26IP2JB008449; Thu, 6 Mar 2008 10:25:16 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0082NN5ZQK00@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 11:25:11 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB003OVN5YPI30@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 11:25:11 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26IPAqF042926; Thu, 06 Mar 2008 10:25:10 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26IPAqF003251; Thu, 06 Mar 2008 10:25:10 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m26IPAlF003250; Thu, 06 Mar 2008 10:25:10 -0800 (PST) Date: Thu, 06 Mar 2008 10:25:09 -0800 From: Danek Duvall Subject: Re: Is this API change allowed in a minor release? In-reply-to: <47CFAFE3.7010402@sun.com> To: James Cheng Cc: lsarc@sun.com, "viseng@Sun.COM" Message-id: <20080306182509.GH9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> <47CFAFE3.7010402@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Content-Length: 160 Lines: 7 Okay. I'll run a fast-track for this (to timeout a week from yesterday), and copy this thread into its mail log. Care to give me a case title? Thanks, Danek From owner-lsarc Thu Mar 6 11:06:49 2008 Return-Path: Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26J6mY1029379 for ; Thu, 6 Mar 2008 11:06:49 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26J6bIl018614; Thu, 6 Mar 2008 19:06:44 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00601P36JM00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 11:06:42 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB0055HP36YM20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 11:06:42 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26J6g7h023592; Thu, 06 Mar 2008 11:06:42 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00A01NO9YU00@fe-sfbay-09.sun.com> (original mail from James.Cheng@Sun.COM); Thu, 06 Mar 2008 11:06:42 -0800 (PST) Received: from [129.146.228.19] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB00ALVP17Y7H0@fe-sfbay-09.sun.com>; Thu, 06 Mar 2008 11:05:31 -0800 (PST) Date: Thu, 06 Mar 2008 11:05:31 -0800 From: James Cheng Subject: Re: Is this API change allowed in a minor release? In-reply-to: <20080306182509.GH9130@zruty.sfbay.sun.com> Sender: James.Cheng@sun.com To: Danek Duvall Cc: lsarc@sun.com, "viseng@Sun.COM" Reply-to: James.Cheng@sun.com Message-id: <47D0407B.1040809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> <47CFAFE3.7010402@sun.com> <20080306182509.GH9130@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Content-Length: 412 Lines: 14 Danek, > I'll run a fast-track for this (to timeout a week from yesterday), and copy > this thread into its mail log. Care to give me a case title? We have 40+ functions like that. Do we need to document all of them now for the case? As for case title, can we call it "mediaLib 2.6" or "mediaLib 2.5.1"? It's kind of bug fixing, but it's fixing the spec and API, so the former seems better. Thanks, -James From owner-lsarc Thu Mar 6 11:13:04 2008 Return-Path: Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JD49S029497 for ; Thu, 6 Mar 2008 11:13:04 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JCxSv021222; Thu, 6 Mar 2008 19:13:00 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00709PDN3700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 11:12:59 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB005X3PDMYM50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Mar 2008 11:12:58 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m26JCwmw022198; Thu, 06 Mar 2008 11:12:58 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26JCwcX003811; Thu, 06 Mar 2008 11:12:58 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m26JCwpt003810; Thu, 06 Mar 2008 11:12:58 -0800 (PST) Date: Thu, 06 Mar 2008 11:12:58 -0800 From: Danek Duvall Subject: Re: Is this API change allowed in a minor release? In-reply-to: <47D0407B.1040809@Sun.COM> To: James Cheng Cc: lsarc@sun.com, "viseng@Sun.COM" Message-id: <20080306191258.GI9130@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> <47CFAFE3.7010402@sun.com> <20080306182509.GH9130@zruty.sfbay.sun.com> <47D0407B.1040809@Sun.COM> User-Agent: Mutt/1.5.16 (2007-06-27) Content-Length: 626 Lines: 18 On Thu, Mar 06, 2008 at 11:05:31AM -0800, James Cheng wrote: > We have 40+ functions like that. Do we need to document all of them now > for the case? A list of the affected functions and arguments would be good, yes. > As for case title, can we call it "mediaLib 2.6" or "mediaLib 2.5.1"? > It's kind of bug fixing, but it's fixing the spec and API, so the former > seems better. Don't think of it as a release of mediaLib -- it's just a change. That change is appropriate for a Minor release of mediaLib, but may be only one of many changes going into that release. What would you call this particular change? Danek From owner-lsarc Thu Mar 6 11:30:31 2008 Return-Path: Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26JUVPQ029803 for ; Thu, 6 Mar 2008 11:30:31 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m26JUTQY028178; Thu, 6 Mar 2008 11:30:29 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB0022NQ6TB500@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 11:30:29 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB00I00Q6SUQE0@nwk-avmta-2.sfbay.sun.com>; Thu, 06 Mar 2008 11:30:28 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26JUSVt028218; Thu, 06 Mar 2008 11:30:28 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00E01PAFMT00@fe-sfbay-10.sun.com> (original mail from James.Cheng@Sun.COM); Thu, 06 Mar 2008 11:30:28 -0800 (PST) Received: from [129.146.228.168] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB009C9Q6PZM50@fe-sfbay-10.sun.com>; Thu, 06 Mar 2008 11:30:25 -0800 (PST) Date: Thu, 06 Mar 2008 11:30:24 -0800 From: James Cheng Subject: Re: Is this API change allowed in a minor release? In-reply-to: <20080306191258.GI9130@zruty.sfbay.sun.com> Sender: James.Cheng@sun.com To: Danek Duvall Cc: lsarc@sun.com, "viseng@Sun.COM" Reply-to: James.Cheng@sun.com Message-id: <47D04650.4020703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> <47CFAFE3.7010402@sun.com> <20080306182509.GH9130@zruty.sfbay.sun.com> <47D0407B.1040809@Sun.COM> <20080306191258.GI9130@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Content-Length: 875 Lines: 27 On 3/6/2008 11:12 AM, Danek Duvall wrote: > On Thu, Mar 06, 2008 at 11:05:31AM -0800, James Cheng wrote: > >> We have 40+ functions like that. Do we need to document all of them now >> for the case? > > A list of the affected functions and arguments would be good, yes. I will provide the list shortly. >> As for case title, can we call it "mediaLib 2.6" or "mediaLib 2.5.1"? >> It's kind of bug fixing, but it's fixing the spec and API, so the former >> seems better. > > Don't think of it as a release of mediaLib -- it's just a change. That > change is appropriate for a Minor release of mediaLib, but may be only one > of many changes going into that release. Exactly. > What would you call this particular change? How about "fixing API ambiguity in some video color conversion functions -- changing argument type from mlib_u32 * to mlib_u8 *"? Thanks, -James From owner-lsarc Thu Mar 6 12:29:52 2008 Return-Path: Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26KTpfg003768 for ; Thu, 6 Mar 2008 12:29:51 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m26KTLiU022767; Fri, 7 Mar 2008 04:29:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXB00H19SXMV000@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 13:29:46 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXB003VHSXKPM90@brm-avmta-1.central.sun.com>; Thu, 06 Mar 2008 13:29:44 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m26KTimX005516; Thu, 06 Mar 2008 12:29:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXB00E01SUCOJ00@fe-sfbay-10.sun.com> (original mail from James.Cheng@Sun.COM); Thu, 06 Mar 2008 12:29:44 -0800 (PST) Received: from [129.146.228.19] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXB007FESXIFJ30@fe-sfbay-10.sun.com>; Thu, 06 Mar 2008 12:29:42 -0800 (PST) Date: Thu, 06 Mar 2008 12:29:41 -0800 From: James Cheng Subject: Re: Is this API change allowed in a minor release? In-reply-to: <47D04650.4020703@sun.com> Sender: James.Cheng@sun.com To: Danek Duvall Cc: lsarc@sun.com, "viseng@Sun.COM" Reply-to: James.Cheng@sun.com Message-id: <47D05435.9050604@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_3puOqRQDAOY/5KyDpgQ4nQ)" X-PMX-Version: 5.2.0.264296 References: <47C49D50.7060909@sun.com> <20080306034910.GM296@zruty.sfbay.sun.com> <47CF931C.2040602@sun.com> <20080306071302.GR296@zruty.sfbay.sun.com> <47CFAFE3.7010402@sun.com> <20080306182509.GH9130@zruty.sfbay.sun.com> <47D0407B.1040809@Sun.COM> <20080306191258.GI9130@zruty.sfbay.sun.com> <47D04650.4020703@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Content-Length: 3613 Lines: 95 This is a multi-part message in MIME format. --Boundary_(ID_3puOqRQDAOY/5KyDpgQ4nQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Danek, Attached please find a list of functions affected by this change. Please let me know if you need more info or materials. Thanks, -James --Boundary_(ID_3puOqRQDAOY/5KyDpgQ4nQ) Content-type: text/plain; name=mlib_api_fix.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=mlib_api_fix.txt Fixing API ambiguity in some video color conversion functions -- changing argument type from mlib_u32 * to mlib_u8 * 3/06/08 james.cheng@sun.com There are the following 41 functions in mediaLib 2.5 which have arguments of type mlib_u32 *: mlib_VideoColorABGRint_to_ARGBint mlib_VideoColorBGRAint_to_ABGRint mlib_VideoColorBGRint_to_ABGRint mlib_VideoColorBlendABGR mlib_VideoColorBlendABGR_Inp mlib_VideoColorBlendABGR_ResetAlpha mlib_VideoColorBlendABGR_ResetAlpha_Inp mlib_VideoColorRGBint_to_ABGRint mlib_VideoColorRGBseq_to_ABGRint mlib_VideoColorRGBXint_to_ABGRint mlib_VideoColorRGBXint_to_ARGBint mlib_VideoColorUYV444int_to_ABGRint mlib_VideoColorUYV444int_to_ARGBint mlib_VideoColorUYV444int_to_UYVY422int mlib_VideoColorUYV444int_to_YUYV422int mlib_VideoColorUYVY422int_to_ABGRint mlib_VideoColorUYVY422int_to_ARGBint mlib_VideoColorXRGBint_to_ABGRint mlib_VideoColorXRGBint_to_ARGBint mlib_VideoColorYUV411seq_to_ABGRint mlib_VideoColorYUV411seq_to_ARGBint mlib_VideoColorYUV411seq_to_UYVY422int mlib_VideoColorYUV411seq_to_YUYV422int mlib_VideoColorYUV420seq_to_ABGRint mlib_VideoColorYUV420seq_to_ARGBint mlib_VideoColorYUV420seq_to_UYVY422int mlib_VideoColorYUV420seq_to_YUYV422int mlib_VideoColorYUV422seq_to_ABGRint mlib_VideoColorYUV422seq_to_ARGBint mlib_VideoColorYUV422seq_to_UYVY422int mlib_VideoColorYUV422seq_to_YUYV422int mlib_VideoColorYUV444int_to_ABGRint mlib_VideoColorYUV444int_to_ARGBint mlib_VideoColorYUV444int_to_UYVY422int mlib_VideoColorYUV444int_to_YUYV422int mlib_VideoColorYUV444seq_to_ABGRint mlib_VideoColorYUV444seq_to_ARGBint mlib_VideoColorYUV444seq_to_UYVY422int mlib_VideoColorYUV444seq_to_YUYV422int mlib_VideoColorYUYV422int_to_ABGRint mlib_VideoColorYUYV422int_to_ARGBint The functions were not specified very clearly, but they were implemented in a way that they work identically on both SPARC and x86. In other words, they were implemented as if those arguments were of type mlib_u8 * and the color components (A, R, G, B, X, Y, U, and V) were assumed to be laid out in memory in the order as shown in the function and argument names. The ambiguity caused the Java wrappers of those functions, implemented with int[] arguments, behave differently from the pure Java implementation of those methods, where int[] can not be cast to byte[], on x86. We could reorder bytes in the Java wrappers on x86, but it'd make the wrappers slower and, more importantly, the method names would not match their behaviors on x86. The easiest and best way of fixing this problem appears to be that we change those arguments from type mlib_u32 * to mlib_u8 * with a restriction of 4-byte alignment on those pointers. The implementation will not be changed, as the pointers are cast to mlib_u8 * (or mlib_d64 * in case of VIS, or __m128i * in case of SSE2, when the pointers are aligned) already in current implementation. Therefore, the ABI will not be changed. --Boundary_(ID_3puOqRQDAOY/5KyDpgQ4nQ)-- From sacadmin Thu Mar 6 12:49:16 2008 Received: from zruty.sfbay.sun.com (zruty [129.146.168.40]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m26KnGmq005480; Thu, 6 Mar 2008 12:49:16 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m26KnGmA004970; Thu, 6 Mar 2008 12:49:16 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m26KnGXP004966; Thu, 6 Mar 2008 12:49:16 -0800 (PST) Date: Thu, 6 Mar 2008 12:49:16 -0800 (PST) From: Danek Duvall Message-Id: <200803062049.m26KnGXP004966@zruty.sfbay.sun.com> To: LSARC-record@sac.sfbay.sun.com Subject: mediaLib argument ambiguity clarification [LSARC/2008/182 FastTrack timeout 03/12/2008] Status: RO Content-Length: 579 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: mediaLib argument ambiguity clarification 1.2. Name of Document Author/Supplier: Author: James Cheng 1.3 Date of This Document: 06 March, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: unknown 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open