|
Home > Archive > Macromedia Flash Server > April 2005 > handwriting array data
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
handwriting array data
|
|
| Andreas Rønning 2005-04-07, 5:55 pm |
| Doing a handwriting chat for tablet pcs on a closed lan, so the network
speed isn't really a problem.
As points are drawn, an object is pushed into an array such as this:
{type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a moveTo, 0
meaning it's a lineTo.
Usually these arrays are around 150-250 in length, tho i can imagine
they will reach around 800 elements in length if the users do a whole
lot of meaningless scribbling and drawing (which happens), even after
optimizing (removing points within a certain proximity).
I'm not using sharedobjects for this data, but rather a direct push type
of chat since its more like msn than irc (1 on 1 chatting rather than 1
on everyone).
I don't have the hardware to test this on right now aside from a couple
of tablet pcs, but there will eventually be around 20 clients at any one
time. Do you think pushing arrays of objects the size i describe will be
safe? Its getting me nervous right now
- Andreas
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Srinivas Manapragada 2005-04-07, 5:55 pm |
| When you send objects, the entire object description has to be sent - the
names and type of each member along with the value - this can be inefficient
for large arrays of similar objects. For your case packing all the
coordinate and move/line operation info into an int and sending an array of
ints will be substantially more efficient. There is a limit as to how much
data you can send in a single remote call, so making your data compact will
reduce your chances of hitting that limit.
Here's some pseudo code to pack and unpack your points
function pack_point( type, x, y ) {
return ((type&0x0f)<<24) | ((x&0xfff)<<12) | (y&0xfff);
}
function unpack_point( p ) {
var type = ((p&0x0f000000)>>24);
var x = ((p&0x00fff000)>>12);
var y = (p&0x00000fff);
return {type:type, x:x, y:y};
}
The above basically represents the coordinate information as 12 bits each,
usable for screen sizes below 4096x4096 pixels. The draw operation is
represented by four bits, more than sufficient for representing your moveto
and lineto operations, but you could potentially have upto 14 additional
ops.
The above representation is very compact, sending it as an object would have
taken almost 4 times more bytes per point.
Srinivas
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
Sent: Wednesday, March 23, 2005 5:46 AM
To: FlashComm Mailing List
Subject: [FlashComm] handwriting array data
Doing a handwriting chat for tablet pcs on a closed lan, so the network
speed isn't really a problem.
As points are drawn, an object is pushed into an array such as this:
{type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a moveTo, 0
meaning it's a lineTo.
Usually these arrays are around 150-250 in length, tho i can imagine
they will reach around 800 elements in length if the users do a whole
lot of meaningless scribbling and drawing (which happens), even after
optimizing (removing points within a certain proximity).
I'm not using sharedobjects for this data, but rather a direct push type
of chat since its more like msn than irc (1 on 1 chatting rather than 1
on everyone).
I don't have the hardware to test this on right now aside from a couple
of tablet pcs, but there will eventually be around 20 clients at any one
time. Do you think pushing arrays of objects the size i describe will be
safe? Its getting me nervous right now
- Andreas
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-04-07, 5:55 pm |
|
Srinivas,
I am facing exactly the same challenge with a freehand drawing board and I
currently sync large arrays filled with objects just like Andreas.
How would I add the int to my array once packed, is that done as usual
simply with a push?
(As we Germans tend to say: I am standing on the hosepipe at the moment :-)
Thanks for any more info you can give.
Stefan
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Srinivas Manapragada
> Sent: 23 March 2005 18:09
> To: FlashComm Mailing List
> Subject: RE: [FlashComm] handwriting array data
>
> When you send objects, the entire object description has to
> be sent - the names and type of each member along with the
> value - this can be inefficient for large arrays of similar
> objects. For your case packing all the coordinate and
> move/line operation info into an int and sending an array of
> ints will be substantially more efficient. There is a limit
> as to how much data you can send in a single remote call, so
> making your data compact will reduce your chances of hitting
> that limit.
>
> Here's some pseudo code to pack and unpack your points
>
> function pack_point( type, x, y ) {
> return ((type&0x0f)<<24) | ((x&0xfff)<<12) | (y&0xfff); }
>
> function unpack_point( p ) {
> var type = ((p&0x0f000000)>>24);
> var x = ((p&0x00fff000)>>12);
> var y = (p&0x00000fff);
> return {type:type, x:x, y:y};
> }
>
> The above basically represents the coordinate information as
> 12 bits each, usable for screen sizes below 4096x4096 pixels.
> The draw operation is represented by four bits, more than
> sufficient for representing your moveto and lineto
> operations, but you could potentially have upto 14 additional ops.
>
> The above representation is very compact, sending it as an
> object would have taken almost 4 times more bytes per point.
>
> Srinivas
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
> Sent: Wednesday, March 23, 2005 5:46 AM
> To: FlashComm Mailing List
> Subject: [FlashComm] handwriting array data
>
> Doing a handwriting chat for tablet pcs on a closed lan, so
> the network speed isn't really a problem.
> As points are drawn, an object is pushed into an array such as this:
> {type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a
> moveTo, 0 meaning it's a lineTo.
> Usually these arrays are around 150-250 in length, tho i can
> imagine they will reach around 800 elements in length if the
> users do a whole lot of meaningless scribbling and drawing
> (which happens), even after optimizing (removing points
> within a certain proximity).
> I'm not using sharedobjects for this data, but rather a
> direct push type of chat since its more like msn than irc (1
> on 1 chatting rather than 1 on everyone).
>
> I don't have the hardware to test this on right now aside
> from a couple of tablet pcs, but there will eventually be
> around 20 clients at any one time. Do you think pushing
> arrays of objects the size i describe will be safe? Its
> getting me nervous right now
>
> - Andreas
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Andreas Rønning 2005-04-07, 5:55 pm |
| Guy, you just saved me a hell of a lot of work. Words cannot express my
gratitude 
- Andreas
Srinivas Manapragada wrote:
>When you send objects, the entire object description has to be sent - the
>names and type of each member along with the value - this can be inefficient
>for large arrays of similar objects. For your case packing all the
>coordinate and move/line operation info into an int and sending an array of
>ints will be substantially more efficient. There is a limit as to how much
>data you can send in a single remote call, so making your data compact will
>reduce your chances of hitting that limit.
>
>Here's some pseudo code to pack and unpack your points
>
>function pack_point( type, x, y ) {
> return ((type&0x0f)<<24) | ((x&0xfff)<<12) | (y&0xfff);
>}
>
>function unpack_point( p ) {
> var type = ((p&0x0f000000)>>24);
> var x = ((p&0x00fff000)>>12);
> var y = (p&0x00000fff);
> return {type:type, x:x, y:y};
>}
>
>The above basically represents the coordinate information as 12 bits each,
>usable for screen sizes below 4096x4096 pixels. The draw operation is
>represented by four bits, more than sufficient for representing your moveto
>and lineto operations, but you could potentially have upto 14 additional
>ops.
>
>The above representation is very compact, sending it as an object would have
>taken almost 4 times more bytes per point.
>
>Srinivas
>
>-----Original Message-----
>From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
>[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
>Sent: Wednesday, March 23, 2005 5:46 AM
>To: FlashComm Mailing List
>Subject: [FlashComm] handwriting array data
>
>Doing a handwriting chat for tablet pcs on a closed lan, so the network
>speed isn't really a problem.
>As points are drawn, an object is pushed into an array such as this:
>{type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a moveTo, 0
>meaning it's a lineTo.
>Usually these arrays are around 150-250 in length, tho i can imagine
>they will reach around 800 elements in length if the users do a whole
>lot of meaningless scribbling and drawing (which happens), even after
>optimizing (removing points within a certain proximity).
>I'm not using sharedobjects for this data, but rather a direct push type
>of chat since its more like msn than irc (1 on 1 chatting rather than 1
>on everyone).
>
>I don't have the hardware to test this on right now aside from a couple
>of tablet pcs, but there will eventually be around 20 clients at any one
>time. Do you think pushing arrays of objects the size i describe will be
>safe? Its getting me nervous right now
>
>- Andreas
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Andreas Rønning 2005-04-07, 5:55 pm |
| One possible niggle i came across was the fact that decimals are
removed. This results in somewhat jagged lines. No big deal, but i'm
sure i'll get remarks.
First thing that came to mind was to count the number of decimals in a
number and multiply it by 100/1000 depending on the count, sending
another 2 integer along with the rest of the packed point (0xf0 and 0x0f
for x and y) telling the recipient how to multiply the numbers its unpacked.
Any ideas? I have *never* used bitwise operators before and i'm
completely baffled by how they work, never mind how your functions work.
- Andreas
Srinivas Manapragada wrote:
>When you send objects, the entire object description has to be sent - the
>names and type of each member along with the value - this can be inefficient
>for large arrays of similar objects. For your case packing all the
>coordinate and move/line operation info into an int and sending an array of
>ints will be substantially more efficient. There is a limit as to how much
>data you can send in a single remote call, so making your data compact will
>reduce your chances of hitting that limit.
>
>Here's some pseudo code to pack and unpack your points
>
>function pack_point( type, x, y ) {
> return ((type&0x0f)<<24) | ((x&0xfff)<<12) | (y&0xfff);
>}
>
>function unpack_point( p ) {
> var type = ((p&0x0f000000)>>24);
> var x = ((p&0x00fff000)>>12);
> var y = (p&0x00000fff);
> return {type:type, x:x, y:y};
>}
>
>The above basically represents the coordinate information as 12 bits each,
>usable for screen sizes below 4096x4096 pixels. The draw operation is
>represented by four bits, more than sufficient for representing your moveto
>and lineto operations, but you could potentially have upto 14 additional
>ops.
>
>The above representation is very compact, sending it as an object would have
>taken almost 4 times more bytes per point.
>
>Srinivas
>
>-----Original Message-----
>From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
>[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
>Sent: Wednesday, March 23, 2005 5:46 AM
>To: FlashComm Mailing List
>Subject: [FlashComm] handwriting array data
>
>Doing a handwriting chat for tablet pcs on a closed lan, so the network
>speed isn't really a problem.
>As points are drawn, an object is pushed into an array such as this:
>{type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a moveTo, 0
>meaning it's a lineTo.
>Usually these arrays are around 150-250 in length, tho i can imagine
>they will reach around 800 elements in length if the users do a whole
>lot of meaningless scribbling and drawing (which happens), even after
>optimizing (removing points within a certain proximity).
>I'm not using sharedobjects for this data, but rather a direct push type
>of chat since its more like msn than irc (1 on 1 chatting rather than 1
>on everyone).
>
>I don't have the hardware to test this on right now aside from a couple
>of tablet pcs, but there will eventually be around 20 clients at any one
>time. Do you think pushing arrays of objects the size i describe will be
>safe? Its getting me nervous right now
>
>- Andreas
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Srinivas Manapragada 2005-04-07, 5:56 pm |
| Yes, you would simply push the resulting int from a packing operation into
your array.
Srinivas
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
Sent: Thursday, March 24, 2005 12:58 AM
To: 'FlashComm Mailing List'
Subject: RE: [FlashComm] handwriting array data
Srinivas,
I am facing exactly the same challenge with a freehand drawing board and I
currently sync large arrays filled with objects just like Andreas.
How would I add the int to my array once packed, is that done as usual
simply with a push?
(As we Germans tend to say: I am standing on the hosepipe at the moment :-)
Thanks for any more info you can give.
Stefan
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Srinivas Manapragada
> Sent: 23 March 2005 18:09
> To: FlashComm Mailing List
> Subject: RE: [FlashComm] handwriting array data
>
> When you send objects, the entire object description has to
> be sent - the names and type of each member along with the
> value - this can be inefficient for large arrays of similar
> objects. For your case packing all the coordinate and
> move/line operation info into an int and sending an array of
> ints will be substantially more efficient. There is a limit
> as to how much data you can send in a single remote call, so
> making your data compact will reduce your chances of hitting
> that limit.
>
> Here's some pseudo code to pack and unpack your points
>
> function pack_point( type, x, y ) {
> return ((type&0x0f)<<24) | ((x&0xfff)<<12) | (y&0xfff); }
>
> function unpack_point( p ) {
> var type = ((p&0x0f000000)>>24);
> var x = ((p&0x00fff000)>>12);
> var y = (p&0x00000fff);
> return {type:type, x:x, y:y};
> }
>
> The above basically represents the coordinate information as
> 12 bits each, usable for screen sizes below 4096x4096 pixels.
> The draw operation is represented by four bits, more than
> sufficient for representing your moveto and lineto
> operations, but you could potentially have upto 14 additional ops.
>
> The above representation is very compact, sending it as an
> object would have taken almost 4 times more bytes per point.
>
> Srinivas
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
> Sent: Wednesday, March 23, 2005 5:46 AM
> To: FlashComm Mailing List
> Subject: [FlashComm] handwriting array data
>
> Doing a handwriting chat for tablet pcs on a closed lan, so
> the network speed isn't really a problem.
> As points are drawn, an object is pushed into an array such as this:
> {type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a
> moveTo, 0 meaning it's a lineTo.
> Usually these arrays are around 150-250 in length, tho i can
> imagine they will reach around 800 elements in length if the
> users do a whole lot of meaningless scribbling and drawing
> (which happens), even after optimizing (removing points
> within a certain proximity).
> I'm not using sharedobjects for this data, but rather a
> direct push type of chat since its more like msn than irc (1
> on 1 chatting rather than 1 on everyone).
>
> I don't have the hardware to test this on right now aside
> from a couple of tablet pcs, but there will eventually be
> around 20 clients at any one time. Do you think pushing
> arrays of objects the size i describe will be safe? Its
> getting me nervous right now
>
> - Andreas
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Srinivas Manapragada 2005-04-07, 5:56 pm |
| The jagginess is due to exact integer representation and can be easily
removed by maintaining sub-pixel information in the coordinates. Typically
4x4 or 16 sub-pixels per real pixel should be sufficient to achieve a smooth
appearance. We will do this by representing the coordinates by a fixed point
number with 2 binary bits of information after the binary point (similar to
a decimal point). We will use 14 bits for each coordinate, the integral
portion is still represented by 12 bits allowing for 4096x4096 raster as
before, and the additional 2 bits provides for the subpixel information. Of
course since we are using more bits, we will have to reduce the bits we used
earlier to represent your moveto/lineto operations. So here are the new
functions with sub-pixel support -
function pack_point( type, x, y ) {
return ((type&0x3)<<28) | (((x*4)&0x3fff)<<14) | ((y*4)&0x3fff);
}
function unpack_point( p ) {
var type = ((p&0x30000000)>>28);
var x = 0.25*((p&0x0fffc000)>>14);
var y = 0.25*(p&0x00003fff);
return {type:type, x:x, y:y};
}
The above still let's you pack the coordinates into an int, and should get
rid of the jaggies. The type can now have only 4 distinct values since it
now only has two bits of representation, which should still be ample, since
it can still represent 0 and 1 (moveto/lineto), and still leaves 3 and 4
unused for future operation types.
Try the above out, if it still doesn't completely remove the jaggies, then
you may have to switch to using two ints to represent your coordinates.
Srinivas
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
Sent: Thursday, March 24, 2005 7:34 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] handwriting array data
One possible niggle i came across was the fact that decimals are
removed. This results in somewhat jagged lines. No big deal, but i'm
sure i'll get remarks.
First thing that came to mind was to count the number of decimals in a
number and multiply it by 100/1000 depending on the count, sending
another 2 integer along with the rest of the packed point (0xf0 and 0x0f
for x and y) telling the recipient how to multiply the numbers its unpacked.
Any ideas? I have *never* used bitwise operators before and i'm
completely baffled by how they work, never mind how your functions work.
- Andreas
Srinivas Manapragada wrote:
>When you send objects, the entire object description has to be sent - the
>names and type of each member along with the value - this can be
inefficient
>for large arrays of similar objects. For your case packing all the
>coordinate and move/line operation info into an int and sending an array of
>ints will be substantially more efficient. There is a limit as to how much
>data you can send in a single remote call, so making your data compact will
>reduce your chances of hitting that limit.
>
>Here's some pseudo code to pack and unpack your points
>
>function pack_point( type, x, y ) {
> return ((type&0x0f)<<24) | ((x&0xfff)<<12) | (y&0xfff);
>}
>
>function unpack_point( p ) {
> var type = ((p&0x0f000000)>>24);
> var x = ((p&0x00fff000)>>12);
> var y = (p&0x00000fff);
> return {type:type, x:x, y:y};
>}
>
>The above basically represents the coordinate information as 12 bits each,
>usable for screen sizes below 4096x4096 pixels. The draw operation is
>represented by four bits, more than sufficient for representing your moveto
>and lineto operations, but you could potentially have upto 14 additional
>ops.
>
>The above representation is very compact, sending it as an object would
have
>taken almost 4 times more bytes per point.
>
>Srinivas
>
>-----Original Message-----
>From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
>[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]
>Sent: Wednesday, March 23, 2005 5:46 AM
>To: FlashComm Mailing List
>Subject: [FlashComm] handwriting array data
>
>Doing a handwriting chat for tablet pcs on a closed lan, so the network
>speed isn't really a problem.
>As points are drawn, an object is pushed into an array such as this:
>{type:0,x:1,y:1} where type is 0 or 1, 1 meaning it is a moveTo, 0
>meaning it's a lineTo.
>Usually these arrays are around 150-250 in length, tho i can imagine
>they will reach around 800 elements in length if the users do a whole
>lot of meaningless scribbling and drawing (which happens), even after
>optimizing (removing points within a certain proximity).
>I'm not using sharedobjects for this data, but rather a direct push type
>of chat since its more like msn than irc (1 on 1 chatting rather than 1
>on everyone).
>
>I don't have the hardware to test this on right now aside from a couple
>of tablet pcs, but there will eventually be around 20 clients at any one
>time. Do you think pushing arrays of objects the size i describe will be
>safe? Its getting me nervous right now
>
>- Andreas
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>=-----------------------------------------------------------
>Supported by Fig Leaf Software - http://www.figleaf.com
>=-----------------------------------------------------------
>
>To change your subscription options or search the archive:
>http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|
|
|
|
|