will java be slow if it has to redraw 1000 small images? 3

[joelwenzel]

I am developing a jigsaw puzzle applet and am concerned about how to join the pieces. I could either

a)join all the small images with code but not actually join the image. In this case, if the puzzle was completed or nearly completed, and I select the puzzle and move a section containing a large number of pieces to a new location, the computer will have to calculate the position and draw each image piece individual. With 1000 pieces, could this be choppy? I mean, 1000 little images all in motion seems like a bunch

b)I could actually merge the pieces together to create one big piece. In this case, I would only have to calculate the position for one big piece and draw one piece (although it would be large than the individual pieces).

Thanks for your help

ps..I know about double buffering and all that stuff. I speaking strikly from a processing power perspective

 

[joelwenzel]

I should mention, that if I was using the (a) method, each piece in the chain of conected pieces would have to have a pointer to it's nearest neighbours which means I would have to recurse though it each time to find all the pieces connected...

I suppose I could have a vector or something that stores all the pieces for a big chunk of the puzzle

 

[sedj]

Of course it all depends on your CPU, graphics card and RAM, but 1000 images ? I'd say it would be slow !

Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[Diancecht]

I'm not sure about the differences that can exist between the two methods, but keep in mind that Java's performance is a little behind native implementations.

Cheers,

Dian

 

[joelwenzel]

ok, I figured this might be a problem. I will just find some way to combine all the images into one new image.

thanks for your help

 

[idarke]

I'm not sure it's that big an issue. If you're moving 1000 pieces with an everage size of 50 pixels each, that's 50,000 pixels to move.

If you combine them all into one big image, you're still moving 50,000 pixels. If you're double-buffering anyway, what would be the difference?

My vote is to code it the easiest way first, and refactor later if performance is a problem.

 

[joelwenzel]

hmmm...well, I'm not sure if even with double buffering it is the same thing because I would have to call

gBuffer.drawImage(image,x,y, this);

1000 times rather then once...but you are right, over all, the same number of pixels would be drawn...and I guess if I am drawing it to a buffer, I'm not "really" drawing it...

But the other thing is that each image is actually an image object which points to its nearest neighbours (top, bottom, right, left) so I would have to recurse though a 1000 images to position them correctly which I would not have to do if I combined them all at once.

But I will think about it...maybe you are right, Maybe I should just try the easiest way, see how it goes, and then change it if it is too choppy. I just don't want to waste time trying to code something if it probably isn't going to work anyway

 

[idarke]

Driving home last night, I realized the problem of recalculating positions of the many objects vs the one.

Melding matched pieces into one piece would be irreversable for the user, but I assume the computer would not allow the user to match two pieces that weren't supposed to go together, so I guess that wouldn't be a problem (in real life, you can get any two pieces to fit if you pound them with your shoe enough).

But if you decide to meld pieces together, you should probably do it when they are matched, rather than when the user tries to move them as a block of pieces. That way, the number of objects you're keeping track of is always getting smaller, and you never have to deal with the problem of moving more than one piece. So the meld option actually has design advantages, as well as speed.

 

[joelwenzel]

yeah..that's what I figured...when the user moves a big block, I don't think I can avoid recalculating all the positions...but hopefully, the usuer won't have to move every piece at once in a block that isn't matched

 

[sedj]

Best advice is - try it, and see what happens ... you can always rewrite things using clever buffering (not double buffering, but loading images upfront, and just moving memory around, as it were).
Good luck !

Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk