Major problem with beginBitmapFill method

[ziibibi]

I am relatively new to Starling and there is a chance that I don't know something essential and that causes a problems, so please do tell me that, if that is a case. But still... What I try to do is drawing extra large (larger than 2048x2048) background bitmap on bottom most level. And since I didn't find any built in method to put image of that size on screen I'm going with splitting that bitmap data into tiles and drawing each of them by separate beginBitmapFill() / drawRect() / endFill(); But it does not work and that is a problem. Instead of expected behavior I receive tiles only party filled with bitmap data I copied as if bitmap would be scaled down upon drawing. (drawRect width and height are exactly the same as width and heght of copyPixels call and same as for bitmap object size) Result looks like this^ And yes I've checked, this works if I replace starling.display.Graphics with ones from flash.display.* Been trying to find a solution for quite a while already and have found none. Any help is appreciated.

[jonathanrpace]

If you resize your source tile images to be sqaure, and a power of two, do you get the same problem?

[ziibibi]

It's magic! Thank you very much Jonathan!

[jonathanrpace]

No worries - it's a problem that a few people have had. And should probably be better signaled in the comments surrounding beginBitmapFill().

The problem is, beginBitmapFill() will automatically convert your bitmap to a Texture for you, and part of this is doing any resizing needed to make it compatible with Stage3D.

Problem is, if you don't know this is happening, your matrix calculations will be off, as you'll be assuming the bitmap's dimensions are the same.

If you're going to be using beginBitmapFill() alot, I strongly suggest you switch over to beginTextureFill() instead. It means you'll have to do a bit of texture resource management yourself, but it will be much more efficient.

If you make multiple beginBitmapFill(), the graphics API isn't smart enough to know it's the same bitmap each time, and will create a fresh Texture for each call. Meaning you've got multiple copies of the same texture sitting in GPU memory.

[ziibibi]

This is good to know I would never have guessed it. By the way I noticed that once I draw this utterly huge bitmap my fps dropped from 60 to somewhere around 30++. Do you think this could be solved by switching to cached textures?