Trimming blitmask.update time plus 'how to' autoUpdate?

[Big Bad Roo]

Hey guys

 

How do you handle/speed up updating display changes with large scrolling data? eg if I click a button in the scroll area, I now need to update the blitmask, which can take a while, and hang the display (button appears sluggish) or stop any new scrolling until it's updated.

 

Also, is blitMask.autoUpdate = true; a substitute for calling blitMask.update(null, true); after any display changes like buttons being switched? I've set blitMask.autoUpdate = true; but it's not updating the blitmask

 

Cheers

[Carl]

When you set blitMask.autoUpdate = true; it just means that the the BlitMask will automatically watch the target to see if its position/scale/rotation has changed on each frame. 

It doesn't monitor new elements being added to the target, animations within the target or any other changes to visual display of the target.

 

So, yes, if you click a button and it is supposed to change to a green color, you would then have to call blitMask.update(null, true) prior to switching the BlitMask back into bitmapMode.

 

Remember, only when a BlitMask is in bitmapMode do you see the performance benefits, and those benefits are only seen when the BlitMask is animating. 

 

more info on update() and bitmapMode here: http://api.greensock.com/as/com/greensock/BlitMask.html#autoUpdate

 

 

----

 

 

 

As for the performance, I'm curious about the size of the BlitMask's target. It is very rare that people  even notice the "bitmap capture" phase taking an inordinate amount of time. Usually people are amazed at how much faster it performs than a normal mask. 

 

But yes, some folks run into trouble. A little while ago someone had a similar issue and we found out they were loading a ton of images that were HD resolution resulting in a bitmap containing 62million pixels. 

 

Perhaps if you can let us know how big your bitmap data actually is, we can have a better idea of whether or not the size of the bitmap is too blame, or perhaps its something else. If anything, it may help folks in the future better gauge what sizes might cause problems.

 

When you start to see the lag in BlitMask get a trace of

 

nameOfYourBlitMaskInstance.target.width

nameOfYourBlitMaskInstance.target.height

[Big Bad Roo]

re autoUpdate - do I need it then? What does it do if the target position has changed that wouldn't happen if you didn't have autoUpdate on?

 

re target size - the width is always 640, and the height is roughly 10 000 for 50 items loaded each pagination search (give or take depending on the text involved).

 

So 4 pagination searches will give you a total height of 40 000.

 

I'm changing my strategy as I've realised this isn't sustainable - continually adding to the size of the target bitmap each search will kill everything pretty quickly.

 

I'm now making it so that 60 items is the most EVER shown, and coding backwards pagination as well as forwards - this will make the bitmap at most 640 x 12000. Backwards pagination will get it's data from the local array holding items already searched, so it should be very fast - just rebuild the sprite holding the search text, and readjust position. Forwards pagination does what it currently does - gets the next 50 items from the server.

 

I'm about 1/2 way through coding it - I'll let you know how it goes.

 

Thanks Carl

[Big Bad Roo]

OK - this way has worked wayyyyy better. The most items ever displayed are 57, but it feels continuous when scrolling through.

 

Cheers Carl.