@horacebury, it’s doable, because I saw it done. maybe is not doable on Corona, that is what I’m debating here, if any internal change on corona part can make things happen faster, I tried all I could think of on my side. and all suggestions till now, I’ve done them all less 1 which I will today.
How many rows do you have on screen at once? I can’t imagine the native apps you are talking about are rendering lots of images of that resolution on the fly.
Could you not have low resolution versions for use in general scrolling, and as soon as the user stops scrolling or zooms in, start to replace the ‘preview’ with the high-res versions.
Hi Carlos,
As you say, a large screen is ~2560 pixels tall. That would be a modern + more powerful device and, because it has such a large resolution, it should (must) have a larger maximum amount of texture memory. So, you can use larger images on that device… but on an old device like the iPad 2 (now about 6 years old?), the resolution is much smaller… so you should not be using incredibly large images on that device.
This is how Corona’s dynamic image selection feature can help you. For smaller screens, you should load smaller images, which will prevent the texture memory from exceeding the maximum and crashing. After all, the screen on the iPad 2 is just 1024 pixels tall and 768 pixels wide, so you don’t need images that are nearly as large as the entire screen on that device.
This will, of course, be more effort on your side because you’ll need to create a different “set” of all images from the professional photographers. However, it should prevent your app from crashing on older devices with smaller screens or lower texture memory.
Brent
@Sphere Game Studios, the 2-pass implementation, I already did that with the same result. getting images from the devices will stutter anyway, that’s what I’m trying to debate here…forget the internet part. that I can handle without a performance hit.
I think you touched the point here. Corona is not multithread.
Putting images inside a newRect is faster than creating a newImageRect? I will try that.
I will give it a try to the scrollView approach again. Thanks for the tips.
@Brent, I sad ipad mini 2, not ipad 2. the resolution of ipad mini 2 is 2048x1536 px. I guess 1024x608 images (i show 2 and a half pictures per screen) are not that large. I scale them down on lower resolution devices. i used to have 3 images resolutions for each image, on older projects. i stopped doing that because I didn’t see any performance impact on scaling the larger image to a lower size on lower resolution devices. like i told you, i did try with lower resolutions pictures with the same result. creating and deleting images on Corona is too CPU intensive. if you can’t do much on your side, i will try to explore more the textures part, which i had success to some extent. maybe i will try to cache to some point, and flush it if it passes that point so it would not crash on older devices.
Is there something about TableView which means you must use TableView?
HI Carlos,
I see… iPad Mini 2 (not iPad 2)… but regardless of anything else, this is an issue of texture memory, not Corona, not TableView vs. ScrollView, not really anything else. If you attempt to load 30-135 images of 1024x608 into memory, all at the same time, you will exceed almost any device’s texture memory and it will crash. There’s simply no realistic way around that.
The reason the Corona TableView was designed to load rows “near when they become visible” is exactly for this reason: some people want TableViews with 500, 1000, or even more rows, and it’s impossible (or hardware limited) to keep that many rows in memory at the same time. Thus, it dynamically loads rows when they’re about to come into view… but if you attempt to load huge images into each row, it will stutter while loading.
ScrollView probably won’t help you much, since you’d still be loading in more images than devices like the iPad Mini 2 can technically handle, based on the actual hardware limitations (not Corona’s).
I’m not sure what else we can advise at this point. You want the highest resolution images possible, and 30-135 of them in memory at the same time, but you also want to run this on somewhat older devices with less texture memory. My suggestion of using lower-resolution images on those devices should help you, but that’s about the only possibility I can imagine considering your goals.
Best regards,
Brent
@carlos, I have an idea if you can do it. Create an HTML page in the format that you want (with the images and text) and then load that into webView and see what the performance is like. You can perfectly emulate a tableView schema like this and you may well find it is a lot smoother.
You can then intercept the click in Corona and then move to your “more details” scene or pop and overlay or whatever.
Posting some code wouldn’t hurt, either.
@Brent, your absolutely right, I can’t put 100 “hight” quality pictures on memory. I’m saying that since my second post (guess no one reads them till the end or my poor English is not letting people understand that).
TableView, is the correct approach, exactly for what you pointed, that’s why I’m using it.
I want 35-100 images, but I don’t want them all in memory (that method is what you suggested and i told that i could not do that for the reasons you know undertand).
i just want a tableview without the stutter. like i told more than 1 time (guess my poor English) having lower resolution pictures won’t solve the problem. I tried that. having 30 or 10000 images should not be an issue because the tableview approach doesn’t depend on the number of elements of the list. the problem is that corona is to slow to render/deleting images, so we need to use alternatives like caching images first which destroys the proposed of the tableview on the first place. if the render/deleting images was faster on corona this problem was not happening and we were not having this discussion. On Corona, defense, like I said, I see this problem on other apps also that don’t use Corona. But i see smooth scrolls also. So I know it’s possible (maybe not on Corona).
@Sphere, that’s a great advice. But I will try first using scrollviews and caching images the most i can (like you suggested) to see if i minimize the problem to an extent i’m happy with. if not, i will try the webview solution.
Hi,
I also get this micro stuttering and have been trying to find the cause.
My images are only 30x30 pixels, one for each row.
- Changing the widget code to preload earlier didnt help much (2 lines that need modification)
- Downloading on the fly vs downloading before inserting made practically no difference (on a 2MB connection)
- Inserting new rows in batches vs on demand, made little difference.
- Using fill.paint is perhaps the method that seem to make a slight difference, but it doesnt remove the stutter on an android tab (Samsung A6)
The culling does not help with the stuttering or the slowdown which progressivly happens as the list gets longer (made it autoscroll indefinately on my device). I notice that what takes longer and longer time is inserting rows, and this is noticeable already after a few hundred lines.
One thing which I did notice is that even with culling, the stutter seem to only occur when new rows are added to the table. Scrolling up and down existing rows works great. I am not technical enough to know how memory management works on devices so perhaps there is some buffering or cache at work which could explain this, or not.
I’ll keep testing if I can think of something else, in the meantime I have to rescue my pizza that should be overdone by now ^^
EDIT, too late! what was once a pizza is now a dark suspicious looking cracker :wacko:
using graphics.newTexture, I was able to “eliminate” the stuttering from tableviews, but I can only use it on small tableviews because it will crash any app if you pre cache a lot of large images.