Thread: [sdljava-users] Anyone using get/setPixelDataXX()?
Status: Beta
Brought to you by:
ivan_ganza
Menu
▾
▴
sdljava-users
|
From: S. Meslin-W. <st...@ta...> - 2005-06-22 16:21:40
|
Hi everyone, I'm cleaning up some code in Odonata and in the sdljava provider I've found that I use get/setPixelData32(long[]). Would it be possible to rationalise the types used for these methods? Does anyone still use them? long[] 64 bit colour data int[] 32 ... short[] 16 ... byte[] 8 ... Essentially it'd mean changing the signatures for the get/set methods to match the bit sizes they're operating with. I've seen the gradual move to using ByteBuffer and Buffers in general... Odonata intends to work with JVM versions 1.1+ so those classes wouldn't necessarily be available on those targets :) Cheers, Steph --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stephane Meslin-Weber Email: st...@ta... Senior Software Engineer Web: http://odonata.tangency.co.uk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Ivan Z. G. <iva...@ya...> - 2005-06-28 03:13:15
|
Hi Steph, Sorry for the late reply I was travelling last week. I think I had this in at one point but then removed it in favour of the byte buffers. Also the get/setPixelDataXXXX methods are VERY inefficient due to the fact this results in copies between java and the native layer. I don't see any harm in providing this methods though so they will be added. Just be aware of the fact they are inefficient. I will add them as soon as I can. Thanks, -Ivan/ S. Meslin-Weber wrote: >Hi everyone, > >I'm cleaning up some code in Odonata and in the sdljava provider I've >found that I use get/setPixelData32(long[]). Would it be possible to >rationalise the types used for these methods? Does anyone still use >them? > >long[] 64 bit colour data >int[] 32 ... >short[] 16 ... >byte[] 8 ... > >Essentially it'd mean changing the signatures for the get/set methods to >match the bit sizes they're operating with. > >I've seen the gradual move to using ByteBuffer and Buffers in general... >Odonata intends to work with JVM versions 1.1+ so those classes wouldn't >necessarily be available on those targets :) > >Cheers, > >Steph > > > |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-08 14:55:48
|
Greetings,
I have checked in code which adds the following methods to SDLSurface:
public long[] getPixelData32()
public int[] getPixelData16()
public short[] getPixelData8()
public void setPixelData32(long[] pixelData)
public void setPixelData16(int[] pixelData)
public void setPixelData8(short[] pixelData)
Cheers,
-Ivan/
S. Meslin-Weber wrote:
>Hi everyone,
>
>I'm cleaning up some code in Odonata and in the sdljava provider I've
>found that I use get/setPixelData32(long[]). Would it be possible to
>rationalise the types used for these methods? Does anyone still use
>them?
>
>long[] 64 bit colour data
>int[] 32 ...
>short[] 16 ...
>byte[] 8 ...
>
>Essentially it'd mean changing the signatures for the get/set methods to
>match the bit sizes they're operating with.
>
>I've seen the gradual move to using ByteBuffer and Buffers in general...
>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>necessarily be available on those targets :)
>
>Cheers,
>
>Steph
>
>
>
|
|
From: S. Meslin-W. <st...@ta...> - 2005-07-12 16:55:26
|
Hi Ivan, Thanks for the additions! Is there a reason for going with long[] for 32bit instead of int[] ? Thanks, Steph On Fri, Jul 08, 2005 at 10:55:19AM -0400, Ivan Z. Ganza wrote: > Greetings, >=20 > I have checked in code which adds the following methods to SDLSurface: >=20 > public long[] getPixelData32() > public int[] getPixelData16() > public short[] getPixelData8() >=20 > public void setPixelData32(long[] pixelData) > public void setPixelData16(int[] pixelData) > public void setPixelData8(short[] pixelData) >=20 > Cheers, > -Ivan/ >=20 > S. Meslin-Weber wrote: >=20 > >Hi everyone, > > > >I'm cleaning up some code in Odonata and in the sdljava provider I've > >found that I use get/setPixelData32(long[]). Would it be possible to > >rationalise the types used for these methods? Does anyone still use > >them? > > > >long[] 64 bit colour data > >int[] 32 ... > >short[] 16 ... > >byte[] 8 ... > > > >Essentially it'd mean changing the signatures for the get/set methods to > >match the bit sizes they're operating with. > > > >I've seen the gradual move to using ByteBuffer and Buffers in general... > >Odonata intends to work with JVM versions 1.1+ so those classes wouldn't > >necessarily be available on those targets :) > > > >Cheers, > > > >Steph > > > >=20 > > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen= ing > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by H= P, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > sdljava-users mailing list > sdl...@li... > https://lists.sourceforge.net/lists/listinfo/sdljava-users --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stephane Meslin-Weber Email: st...@ta... Senior Software Engineer Web: http://odonata.tangency.co.uk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-12 21:54:31
|
Hi Steph,
Not a problem. I did not have time to properly test them, however, the
code was actually still in the native layer from where I first coded
that part , and I know it was working at that point.
The reason for long instead of int is because that is how swig maps it.
void SWIG_GetPixelData32(SDL_Surface *surface, Uint32 pixelData[])
For the above SWIG mapg the Uint32 to a long[]. I suppose we could add
our own (additonal) method with takes an int[] and casts it to long[]
calling the appropriate method (for conviencence). Not sure if that
would cause any problems due to the cast.
-Ivan/
S. Meslin-Weber wrote:
>Hi Ivan,
>
>Thanks for the additions! Is there a reason for going with long[] for
>32bit instead of int[] ?
>
>Thanks,
>
>Steph
>
>On Fri, Jul 08, 2005 at 10:55:19AM -0400, Ivan Z. Ganza wrote:
>
>
>>Greetings,
>>
>>I have checked in code which adds the following methods to SDLSurface:
>>
>> public long[] getPixelData32()
>> public int[] getPixelData16()
>> public short[] getPixelData8()
>>
>> public void setPixelData32(long[] pixelData)
>> public void setPixelData16(int[] pixelData)
>> public void setPixelData8(short[] pixelData)
>>
>>Cheers,
>>-Ivan/
>>
>>S. Meslin-Weber wrote:
>>
>>
>>
>>>Hi everyone,
>>>
>>>I'm cleaning up some code in Odonata and in the sdljava provider I've
>>>found that I use get/setPixelData32(long[]). Would it be possible to
>>>rationalise the types used for these methods? Does anyone still use
>>>them?
>>>
>>>long[] 64 bit colour data
>>>int[] 32 ...
>>>short[] 16 ...
>>>byte[] 8 ...
>>>
>>>Essentially it'd mean changing the signatures for the get/set methods to
>>>match the bit sizes they're operating with.
>>>
>>>I've seen the gradual move to using ByteBuffer and Buffers in general...
>>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>>>necessarily be available on those targets :)
>>>
>>>Cheers,
>>>
>>>Steph
>>>
>>>
>>>
>>>
>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
>>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>>core and dual graphics technology at this free one hour event hosted by HP,
>>AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>
>
>
|
|
From: S. Meslin-W. <st...@ta...> - 2005-07-18 21:19:52
|
Hi Ivan,
On Tue, Jul 12, 2005 at 05:54:19PM -0400, Ivan Z. Ganza wrote:
> Not a problem. I did not have time to properly test them, however, the
> code was actually still in the native layer from where I first coded
> that part , and I know it was working at that point.
Yup, it's back as it was...
> The reason for long instead of int is because that is how swig maps it.
>=20
> void SWIG_GetPixelData32(SDL_Surface *surface, Uint32 pixelData[])
Argh. that's a huge bottleneck for me. I treat ints as uint32 as it is
(for AARRGGBB) and other libraries I use (VNCj notably) also use this
interpretation for int.
> For the above SWIG mapg the Uint32 to a long[]. I suppose we could add
> our own (additonal) method with takes an int[] and casts it to long[]
> calling the appropriate method (for conviencence). Not sure if that
> would cause any problems due to the cast.
No, it's not possible to cast int[] to long[]. I end up having to do the
following:
long[] longs =3D new long[source.length];
for (int i =3D 0; i < source.length; i++) {
longs[i] =3D source[i];
}
SDLUtil.setPixelData32(screen, longs);
You can imagine how expensive this can get :( I don't think that pushing
this to C is the answer. Perhaps SWIG needs fixing?
Steph
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stephane Meslin-Weber Email: st...@ta...
Senior Software Engineer Web: http://odonata.tangency.co.uk
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
|
|
From: Rainer K. <ar...@gm...> - 2005-07-18 22:05:07
|
S. Meslin-Weber wrote:
> Hi Ivan,
>
> On Tue, Jul 12, 2005 at 05:54:19PM -0400, Ivan Z. Ganza wrote:
>
>>Not a problem. I did not have time to properly test them, however, the
>>code was actually still in the native layer from where I first coded
>>that part , and I know it was working at that point.
>
>
> Yup, it's back as it was...
>
>
>>The reason for long instead of int is because that is how swig maps it.
>>
>> void SWIG_GetPixelData32(SDL_Surface *surface, Uint32 pixelData[])
>
>
> Argh. that's a huge bottleneck for me. I treat ints as uint32 as it is
> (for AARRGGBB) and other libraries I use (VNCj notably) also use this
> interpretation for int.
>
>
>>For the above SWIG mapg the Uint32 to a long[]. I suppose we could add
>>our own (additonal) method with takes an int[] and casts it to long[]
>>calling the appropriate method (for conviencence). Not sure if that
>>would cause any problems due to the cast.
>
>
> No, it's not possible to cast int[] to long[]. I end up having to do the
> following:
>
> long[] longs = new long[source.length];
> for (int i = 0; i < source.length; i++) {
> longs[i] = source[i];
> }
> SDLUtil.setPixelData32(screen, longs);
>
> You can imagine how expensive this can get :( I don't think that pushing
> this to C is the answer. Perhaps SWIG needs fixing?
Maybe there's nothing to fix. Java primitives are always signed so the
range is not the same as the unsigned 32 bit int.
Java Data Types:
int
4 bytes, signed (two's complement). -2,147,483,648 to
2,147,483,647. Like all numeric types ints may be cast into other
numeric types (byte, short, long, float, double). When lossy casts are
done (e.g. int to byte) the conversion is done modulo the length of the
smaller type.
long
8 bytes signed (two's complement). Ranges from
-9,223,372,036,854,775,808 to +9,223,372,036,854,775,807.
C:
uint8
0 to 255
Unsigned 8-bit integer
1
uint8
uint16
0 to 65535
Unsigned 16-bit integer
2
uint16
uint32
0 to 4,294,967,295
Unsigned 32-bit integer
4
uint32
|
|
From: S. Meslin-W. <st...@ta...> - 2005-07-18 22:18:47
|
Hi Rainer, On Tue, Jul 19, 2005 at 12:04:57AM +0200, Rainer Koschnick wrote: > Maybe there's nothing to fix. Java primitives are always signed so the= =20 > range is not the same as the unsigned 32 bit int. > > Java Data Types: >=20 > int > 4 bytes, signed (two's complement). -2,147,483,648 to=20 > 2,147,483,647. Like all numeric types ints may be cast into other=20 [snip] So... 32 bits, right? we're dealing with pixel data here, not arithmetic operations. When I deal with colour information, each byte is treated as unsigned and upcasted to int (Java does love its ints); things are then repacked into 32bits, again ignoring signs. The fact that Java deems them signed isn't relevant in this context. So ok, since SWIG is multipurpose, perhaps we simply need to let it know that we have a specific interpretation of these type conversions? Cheers, Steph --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stephane Meslin-Weber Email: st...@ta... Senior Software Engineer Web: http://odonata.tangency.co.uk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-19 02:08:05
|
Interesting... I've had a look at vncJ. I didn't even know such a thing existed. vnc is an awesome program! I'm not sure why the swig team choose to use long. Probably because they wanted to support arithmetic operations. I see now that in our case, since we interpret as pixel data, things are different. I will investigate changing this but only when dealing with pixel data. The other instances of uint32 should remain longs I think. -Ivan/ S. Meslin-Weber wrote: >Hi Rainer, > >On Tue, Jul 19, 2005 at 12:04:57AM +0200, Rainer Koschnick wrote: > > >>Maybe there's nothing to fix. Java primitives are always signed so the >>range is not the same as the unsigned 32 bit int. >> >>Java Data Types: >> >>int >> 4 bytes, signed (two's complement). -2,147,483,648 to >>2,147,483,647. Like all numeric types ints may be cast into other >> >> > >[snip] > >So... 32 bits, right? we're dealing with pixel data here, not arithmetic >operations. When I deal with colour information, each byte is treated as >unsigned and upcasted to int (Java does love its ints); things are then >repacked into 32bits, again ignoring signs. The fact that Java deems >them signed isn't relevant in this context. > >So ok, since SWIG is multipurpose, perhaps we simply need to let it know >that we have a specific interpretation of these type conversions? > >Cheers, > >Steph > > > |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-19 22:37:13
|
Greetings,
I've changed the get/setPixelData32 methods to use int[] instead of
long[]. Please let me know if this is working properly. I didn't have
a chance to test it...
If we find this to be good I'll adjust the other two methods in the same
way. Also I saw one thing that could be optimized which I will also do.
So we should end up with:
get/setPixelData8 --> byte[]
get/setPixelData16 --> short[]
get/setPixelData32 --> int[]
Nothing else anywhere will be affected by this.
Let me know any comments...
-Ivan/
S. Meslin-Weber wrote:
>Hi everyone,
>
>I'm cleaning up some code in Odonata and in the sdljava provider I've
>found that I use get/setPixelData32(long[]). Would it be possible to
>rationalise the types used for these methods? Does anyone still use
>them?
>
>long[] 64 bit colour data
>int[] 32 ...
>short[] 16 ...
>byte[] 8 ...
>
>Essentially it'd mean changing the signatures for the get/set methods to
>match the bit sizes they're operating with.
>
>I've seen the gradual move to using ByteBuffer and Buffers in general...
>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>necessarily be available on those targets :)
>
>Cheers,
>
>Steph
>
>
>
|
|
From: S. Meslin-W. <st...@ta...> - 2005-07-20 21:23:58
|
Hi Ivan, Thanks for looking into this :) I've checked out head from cvs but with my existing .dll the jvm dies; have I missed a step? Wouldn't this kind of change mean regenerating some of the SWIG java and native files? Cheers, Steph On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote: > Greetings, >=20 > I've changed the get/setPixelData32 methods to use int[] instead of > long[]. Please let me know if this is working properly. I didn't have > a chance to test it... >=20 > If we find this to be good I'll adjust the other two methods in the same > way. Also I saw one thing that could be optimized which I will also do. >=20 > So we should end up with: >=20 > get/setPixelData8 --> byte[] > get/setPixelData16 --> short[] > get/setPixelData32 --> int[] >=20 > Nothing else anywhere will be affected by this. >=20 > Let me know any comments... >=20 > -Ivan/ >=20 > S. Meslin-Weber wrote: >=20 > >Hi everyone, > > > >I'm cleaning up some code in Odonata and in the sdljava provider I've > >found that I use get/setPixelData32(long[]). Would it be possible to > >rationalise the types used for these methods? Does anyone still use > >them? > > > >long[] 64 bit colour data > >int[] 32 ... > >short[] 16 ... > >byte[] 8 ... > > > >Essentially it'd mean changing the signatures for the get/set methods to > >match the bit sizes they're operating with. > > > >I've seen the gradual move to using ByteBuffer and Buffers in general... > >Odonata intends to work with JVM versions 1.1+ so those classes wouldn't > >necessarily be available on those targets :) > > > >Cheers, > > > >Steph > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > _______________________________________________ > sdljava-users mailing list > sdl...@li... > https://lists.sourceforge.net/lists/listinfo/sdljava-users --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stephane Meslin-Weber Email: st...@ta... Senior Software Engineer Web: http://odonata.tangency.co.uk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-20 21:52:53
|
Hi Steph,
Yes you need to rebuild the sdljava.dll because the native layer code
changed. As well as recompilation of SDLSurface.java source file.
The files that changed were:
-- native layer
SDLVideo.i
SDLVideo_wrap.c
- java layer
SDLSurface.java
So I regenerated the wrapper file but new shared libraries/dlls need to
be generated.
-Ivan/
S. Meslin-Weber wrote:
>Hi Ivan,
>
>Thanks for looking into this :)
>
>I've checked out head from cvs but with my existing .dll the jvm dies;
>have I missed a step? Wouldn't this kind of change mean regenerating
>some of the SWIG java and native files?
>
>Cheers,
>
>Steph
>
>
>On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote:
>
>
>>Greetings,
>>
>>I've changed the get/setPixelData32 methods to use int[] instead of
>>long[]. Please let me know if this is working properly. I didn't have
>>a chance to test it...
>>
>>If we find this to be good I'll adjust the other two methods in the same
>>way. Also I saw one thing that could be optimized which I will also do.
>>
>>So we should end up with:
>>
>> get/setPixelData8 --> byte[]
>> get/setPixelData16 --> short[]
>> get/setPixelData32 --> int[]
>>
>>Nothing else anywhere will be affected by this.
>>
>>Let me know any comments...
>>
>>-Ivan/
>>
>>S. Meslin-Weber wrote:
>>
>>
>>
>>>Hi everyone,
>>>
>>>I'm cleaning up some code in Odonata and in the sdljava provider I've
>>>found that I use get/setPixelData32(long[]). Would it be possible to
>>>rationalise the types used for these methods? Does anyone still use
>>>them?
>>>
>>>long[] 64 bit colour data
>>>int[] 32 ...
>>>short[] 16 ...
>>>byte[] 8 ...
>>>
>>>Essentially it'd mean changing the signatures for the get/set methods to
>>>match the bit sizes they're operating with.
>>>
>>>I've seen the gradual move to using ByteBuffer and Buffers in general...
>>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't
>>>necessarily be available on those targets :)
>>>
>>>Cheers,
>>>
>>>Steph
>>>
>>>
>>>
>>>
>>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>
>>
>
>
>
|
|
From: S. Meslin-W. <st...@ta...> - 2005-07-21 22:14:19
|
Hi Ivan, Thought so - for some reason the native dir hadn't been updated on my tree so I thought you'd forgotten to push your changes... woops! :) I recompiled the dll (and the java code of course) and now I get an SDL window for a fraction of a second before the JVM crashes; and without any error messages or log files. I'm a bit stumped as JNI is definately beyond my skills - is there anything I can do on my end to speed up the debugging? Thanks, Steph On Wed, Jul 20, 2005 at 05:52:07PM -0400, Ivan Z. Ganza wrote: > Hi Steph, >=20 > Yes you need to rebuild the sdljava.dll because the native layer code > changed. As well as recompilation of SDLSurface.java source file. >=20 > The files that changed were: >=20 > -- native layer > SDLVideo.i > SDLVideo_wrap.c >=20 > - java layer > SDLSurface.java >=20 > So I regenerated the wrapper file but new shared libraries/dlls need to > be generated. >=20 > -Ivan/ >=20 > S. Meslin-Weber wrote: >=20 > >Hi Ivan, > > > >Thanks for looking into this :) > > > >I've checked out head from cvs but with my existing .dll the jvm dies; > >have I missed a step? Wouldn't this kind of change mean regenerating > >some of the SWIG java and native files? > > > >Cheers, > > > >Steph > > > > > >On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote: > > =20 > > > >>Greetings, > >> > >>I've changed the get/setPixelData32 methods to use int[] instead of > >>long[]. Please let me know if this is working properly. I didn't have > >>a chance to test it... > >> > >>If we find this to be good I'll adjust the other two methods in the same > >>way. Also I saw one thing that could be optimized which I will also do. > >> > >>So we should end up with: > >> > >> get/setPixelData8 --> byte[] > >> get/setPixelData16 --> short[] > >> get/setPixelData32 --> int[] > >> > >>Nothing else anywhere will be affected by this. > >> > >>Let me know any comments... > >> > >>-Ivan/ > >> > >>S. Meslin-Weber wrote: > >> > >> =20 > >> > >>>Hi everyone, > >>> > >>>I'm cleaning up some code in Odonata and in the sdljava provider I've > >>>found that I use get/setPixelData32(long[]). Would it be possible to > >>>rationalise the types used for these methods? Does anyone still use > >>>them? > >>> > >>>long[] 64 bit colour data > >>>int[] 32 ... > >>>short[] 16 ... > >>>byte[] 8 ... > >>> > >>>Essentially it'd mean changing the signatures for the get/set methods = to > >>>match the bit sizes they're operating with. > >>> > >>>I've seen the gradual move to using ByteBuffer and Buffers in general.= =2E. > >>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn= 't > >>>necessarily be available on those targets :) > >>> > >>>Cheers, > >>> > >>>Steph > >>> > >>>=20 > >>> > >>> =20 > >>> > >> > >>------------------------------------------------------- > >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>informative Webcasts and more! Get everything you need to get up to > >>speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > >>_______________________________________________ > >>sdljava-users mailing list > >>sdl...@li... > >>https://lists.sourceforge.net/lists/listinfo/sdljava-users > >> =20 > >> > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > _______________________________________________ > sdljava-users mailing list > sdl...@li... > https://lists.sourceforge.net/lists/listinfo/sdljava-users --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stephane Meslin-Weber Email: st...@ta... Senior Software Engineer Web: http://odonata.tangency.co.uk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-22 14:06:44
|
Sounds like I made a mistake in the C code. There should be a jvm crash file that has the VM state in it, if you've got that, post it... -Ivan/ S. Meslin-Weber wrote: >Hi Ivan, > >Thought so - for some reason the native dir hadn't been updated on my >tree so I thought you'd forgotten to push your changes... woops! :) > >I recompiled the dll (and the java code of course) and now I get an SDL >window for a fraction of a second before the JVM crashes; and without >any error messages or log files. > >I'm a bit stumped as JNI is definately beyond my skills - is there >anything I can do on my end to speed up the debugging? > >Thanks, > >Steph > >On Wed, Jul 20, 2005 at 05:52:07PM -0400, Ivan Z. Ganza wrote: > > >>Hi Steph, >> >>Yes you need to rebuild the sdljava.dll because the native layer code >>changed. As well as recompilation of SDLSurface.java source file. >> >>The files that changed were: >> >>-- native layer >> SDLVideo.i >> SDLVideo_wrap.c >> >>- java layer >> SDLSurface.java >> >>So I regenerated the wrapper file but new shared libraries/dlls need to >>be generated. >> >>-Ivan/ >> >>S. Meslin-Weber wrote: >> >> >> >>>Hi Ivan, >>> >>>Thanks for looking into this :) >>> >>>I've checked out head from cvs but with my existing .dll the jvm dies; >>>have I missed a step? Wouldn't this kind of change mean regenerating >>>some of the SWIG java and native files? >>> >>>Cheers, >>> >>>Steph >>> >>> >>>On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote: >>> >>> >>> >>> >>>>Greetings, >>>> >>>>I've changed the get/setPixelData32 methods to use int[] instead of >>>>long[]. Please let me know if this is working properly. I didn't have >>>>a chance to test it... >>>> >>>>If we find this to be good I'll adjust the other two methods in the same >>>>way. Also I saw one thing that could be optimized which I will also do. >>>> >>>>So we should end up with: >>>> >>>> get/setPixelData8 --> byte[] >>>> get/setPixelData16 --> short[] >>>> get/setPixelData32 --> int[] >>>> >>>>Nothing else anywhere will be affected by this. >>>> >>>>Let me know any comments... >>>> >>>>-Ivan/ >>>> >>>>S. Meslin-Weber wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi everyone, >>>>> >>>>>I'm cleaning up some code in Odonata and in the sdljava provider I've >>>>>found that I use get/setPixelData32(long[]). Would it be possible to >>>>>rationalise the types used for these methods? Does anyone still use >>>>>them? >>>>> >>>>>long[] 64 bit colour data >>>>>int[] 32 ... >>>>>short[] 16 ... >>>>>byte[] 8 ... >>>>> >>>>>Essentially it'd mean changing the signatures for the get/set methods to >>>>>match the bit sizes they're operating with. >>>>> >>>>>I've seen the gradual move to using ByteBuffer and Buffers in general... >>>>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't >>>>>necessarily be available on those targets :) >>>>> >>>>>Cheers, >>>>> >>>>>Steph >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>>> >>>> >>>>from IBM. Find simple to follow Roadmaps, straightforward articles, >>> >>> >>>>informative Webcasts and more! Get everything you need to get up to >>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>>>_______________________________________________ >>>>sdljava-users mailing list >>>>sdl...@li... >>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>sdljava-users mailing list >>sdl...@li... >>https://lists.sourceforge.net/lists/listinfo/sdljava-users >> >> > > > |
|
From: S. Meslin-W. <st...@ta...> - 2005-07-22 14:28:38
|
That's the first thing I looked for (usually named hs*.log) and I was surprised that none actually get created :( Steph On Fri, Jul 22, 2005 at 10:06:25AM -0400, Ivan Z. Ganza wrote: > Sounds like I made a mistake in the C code. There should be a jvm crash > file that has the VM state in it, if you've got that, post it... >=20 > -Ivan/ >=20 > S. Meslin-Weber wrote: >=20 > >Hi Ivan, > > > >Thought so - for some reason the native dir hadn't been updated on my > >tree so I thought you'd forgotten to push your changes... woops! :) > > > >I recompiled the dll (and the java code of course) and now I get an SDL > >window for a fraction of a second before the JVM crashes; and without > >any error messages or log files. > > > >I'm a bit stumped as JNI is definately beyond my skills - is there > >anything I can do on my end to speed up the debugging? > > > >Thanks, > > > >Steph > > > >On Wed, Jul 20, 2005 at 05:52:07PM -0400, Ivan Z. Ganza wrote: > > =20 > > > >>Hi Steph, > >> > >>Yes you need to rebuild the sdljava.dll because the native layer code > >>changed. As well as recompilation of SDLSurface.java source file. > >> > >>The files that changed were: > >> > >>-- native layer > >> SDLVideo.i > >> SDLVideo_wrap.c > >> > >>- java layer > >> SDLSurface.java > >> > >>So I regenerated the wrapper file but new shared libraries/dlls need to > >>be generated. > >> > >>-Ivan/ > >> > >>S. Meslin-Weber wrote: > >> > >> =20 > >> > >>>Hi Ivan, > >>> > >>>Thanks for looking into this :) > >>> > >>>I've checked out head from cvs but with my existing .dll the jvm dies; > >>>have I missed a step? Wouldn't this kind of change mean regenerating > >>>some of the SWIG java and native files? > >>> > >>>Cheers, > >>> > >>>Steph > >>> > >>> > >>>On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote: > >>>=20 > >>> > >>> =20 > >>> > >>>>Greetings, > >>>> > >>>>I've changed the get/setPixelData32 methods to use int[] instead of > >>>>long[]. Please let me know if this is working properly. I didn't ha= ve > >>>>a chance to test it... > >>>> > >>>>If we find this to be good I'll adjust the other two methods in the s= ame > >>>>way. Also I saw one thing that could be optimized which I will also = do. > >>>> > >>>>So we should end up with: > >>>> > >>>> get/setPixelData8 --> byte[] > >>>> get/setPixelData16 --> short[] > >>>> get/setPixelData32 --> int[] > >>>> > >>>>Nothing else anywhere will be affected by this. > >>>> > >>>>Let me know any comments... > >>>> > >>>>-Ivan/ > >>>> > >>>>S. Meslin-Weber wrote: > >>>> > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>>>Hi everyone, > >>>>> > >>>>>I'm cleaning up some code in Odonata and in the sdljava provider I've > >>>>>found that I use get/setPixelData32(long[]). Would it be possible to > >>>>>rationalise the types used for these methods? Does anyone still use > >>>>>them? > >>>>> > >>>>>long[] 64 bit colour data > >>>>>int[] 32 ... > >>>>>short[] 16 ... > >>>>>byte[] 8 ... > >>>>> > >>>>>Essentially it'd mean changing the signatures for the get/set method= s to > >>>>>match the bit sizes they're operating with. > >>>>> > >>>>>I've seen the gradual move to using ByteBuffer and Buffers in genera= l... > >>>>>Odonata intends to work with JVM versions 1.1+ so those classes woul= dn't > >>>>>necessarily be available on those targets :) > >>>>> > >>>>>Cheers, > >>>>> > >>>>>Steph > >>>>> > >>>>> > >>>>> > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>>------------------------------------------------------- > >>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>>> =20 > >>>> > >>>>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>> =20 > >>> > >>>>informative Webcasts and more! Get everything you need to get up to > >>>>speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3D= click > >>>>_______________________________________________ > >>>>sdljava-users mailing list > >>>>sdl...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>=20 > >>> > >>> =20 > >>> > >> > >>------------------------------------------------------- > >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > >>from IBM. Find simple to follow Roadmaps, straightforward articles, > >>informative Webcasts and more! Get everything you need to get up to > >>speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > >>_______________________________________________ > >>sdljava-users mailing list > >>sdl...@li... > >>https://lists.sourceforge.net/lists/listinfo/sdljava-users > >> =20 > >> > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > _______________________________________________ > sdljava-users mailing list > sdl...@li... > https://lists.sourceforge.net/lists/listinfo/sdljava-users --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stephane Meslin-Weber Email: st...@ta... Senior Software Engineer Web: http://odonata.tangency.co.uk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Ivan Z. G. <iva...@ya...> - 2005-07-26 01:39:05
|
I'll debug this and fix it as soon as possible. Sorry for the delay in getting this working. Its summer and in Toronto we tend to try to enjoy it as much as possible while its here ;-) -Ivan/ S. Meslin-Weber wrote: >That's the first thing I looked for (usually named hs*.log) and I was >surprised that none actually get created :( > >Steph > >On Fri, Jul 22, 2005 at 10:06:25AM -0400, Ivan Z. Ganza wrote: > > >>Sounds like I made a mistake in the C code. There should be a jvm crash >>file that has the VM state in it, if you've got that, post it... >> >>-Ivan/ >> >>S. Meslin-Weber wrote: >> >> >> >>>Hi Ivan, >>> >>>Thought so - for some reason the native dir hadn't been updated on my >>>tree so I thought you'd forgotten to push your changes... woops! :) >>> >>>I recompiled the dll (and the java code of course) and now I get an SDL >>>window for a fraction of a second before the JVM crashes; and without >>>any error messages or log files. >>> >>>I'm a bit stumped as JNI is definately beyond my skills - is there >>>anything I can do on my end to speed up the debugging? >>> >>>Thanks, >>> >>>Steph >>> >>>On Wed, Jul 20, 2005 at 05:52:07PM -0400, Ivan Z. Ganza wrote: >>> >>> >>> >>> >>>>Hi Steph, >>>> >>>>Yes you need to rebuild the sdljava.dll because the native layer code >>>>changed. As well as recompilation of SDLSurface.java source file. >>>> >>>>The files that changed were: >>>> >>>>-- native layer >>>> SDLVideo.i >>>> SDLVideo_wrap.c >>>> >>>>- java layer >>>> SDLSurface.java >>>> >>>>So I regenerated the wrapper file but new shared libraries/dlls need to >>>>be generated. >>>> >>>>-Ivan/ >>>> >>>>S. Meslin-Weber wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Ivan, >>>>> >>>>>Thanks for looking into this :) >>>>> >>>>>I've checked out head from cvs but with my existing .dll the jvm dies; >>>>>have I missed a step? Wouldn't this kind of change mean regenerating >>>>>some of the SWIG java and native files? >>>>> >>>>>Cheers, >>>>> >>>>>Steph >>>>> >>>>> >>>>>On Tue, Jul 19, 2005 at 06:36:59PM -0400, Ivan Z. Ganza wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Greetings, >>>>>> >>>>>>I've changed the get/setPixelData32 methods to use int[] instead of >>>>>>long[]. Please let me know if this is working properly. I didn't have >>>>>>a chance to test it... >>>>>> >>>>>>If we find this to be good I'll adjust the other two methods in the same >>>>>>way. Also I saw one thing that could be optimized which I will also do. >>>>>> >>>>>>So we should end up with: >>>>>> >>>>>> get/setPixelData8 --> byte[] >>>>>> get/setPixelData16 --> short[] >>>>>> get/setPixelData32 --> int[] >>>>>> >>>>>>Nothing else anywhere will be affected by this. >>>>>> >>>>>>Let me know any comments... >>>>>> >>>>>>-Ivan/ >>>>>> >>>>>>S. Meslin-Weber wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi everyone, >>>>>>> >>>>>>>I'm cleaning up some code in Odonata and in the sdljava provider I've >>>>>>>found that I use get/setPixelData32(long[]). Would it be possible to >>>>>>>rationalise the types used for these methods? Does anyone still use >>>>>>>them? >>>>>>> >>>>>>>long[] 64 bit colour data >>>>>>>int[] 32 ... >>>>>>>short[] 16 ... >>>>>>>byte[] 8 ... >>>>>>> >>>>>>>Essentially it'd mean changing the signatures for the get/set methods to >>>>>>>match the bit sizes they're operating with. >>>>>>> >>>>>>>I've seen the gradual move to using ByteBuffer and Buffers in general... >>>>>>>Odonata intends to work with JVM versions 1.1+ so those classes wouldn't >>>>>>>necessarily be available on those targets :) >>>>>>> >>>>>>>Cheers, >>>>>>> >>>>>>>Steph >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>------------------------------------------------------- >>>>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>from IBM. Find simple to follow Roadmaps, straightforward articles, >>>>> >>>>> >>>>> >>>>> >>>>>>informative Webcasts and more! Get everything you need to get up to >>>>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>>>>>_______________________________________________ >>>>>>sdljava-users mailing list >>>>>>sdl...@li... >>>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>>> >>>> >>>>from IBM. Find simple to follow Roadmaps, straightforward articles, >>> >>> >>>>informative Webcasts and more! Get everything you need to get up to >>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>>>_______________________________________________ >>>>sdljava-users mailing list >>>>sdl...@li... >>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>sdljava-users mailing list >>sdl...@li... >>https://lists.sourceforge.net/lists/listinfo/sdljava-users >> >> > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X