Hi,
I am a computer sciences teacher.
One of my students developed the attached app based on PaintPot.
After clicking btnDownload ("Download the image" - below the Wipe button) the first 2 rows of buttons (horizontal arrangements) disappeared.
I tested on 2 Android Phones - Galaxy S20FE and Galaxy A12) and the issue persisted in both.
Here is a link to the AIA file: https://drive.google.com/file/d/1U9gmFO43dBHXLIzldxDD5l91ef-kRam7/view?usp=sharing
Thank you
I looked closely at the project in the Designer, and remembered a flash of a red error message when it first loaded.
The Table Arrangement looks fishy.
It's got 2 rows and 2 columns, but has 5 components hanging under it in the Components Tree pane. (2*2= 4, right, so how is that possible?)
I recommend nesting Horizontal and Vertical Arrangements as an alternative to using Table Arrangements, because they are internally complex and bug-prone.
Take backups (.aia exports) of this project before trying to replace that Table Arrangement. They get internally tangled under cut and paste operations.
Also, don't mix pixel counts with proportions with automatic sizes. The AI2 component sizing algorithm is a free for all fight for space on the Screen at run time. Pixel counts are unpredictable if the screen is set responsive, because you won't know how many pixels fit on the screen.
Canvas sizes take a moment to calculate, and are unreliable in Screen1.Initialize.
I did a little surgery on Screen1.scm, changing TableArrangement2 to a VerticalArrangement in 7zip. That got all 5 Arrangement subcomponents showing (after setting Screen1 scrollable), but it did not eliminate the error of the top 2 Horizontal Arrangements disappearing.
Setting the top 2 Horizontal Arrangements to 10% Height did not save them from disappearing after the Canvas Save.
Caging the lion (Canvas) in a Vertical Arrangement saved the upper Horizontal Arrangements from being eaten after a Canvas Save.
PaintPot2.aia (44.2 KB)
Good fences make good neighbors in AI2 Screen Design.
I did not look in the other Screens for the transitory red loading warning.
2 Likes
@ABG - Thank you very much for the thorough testing and for the workaround.
@ewpatton - who should I report the issue to, and how, so it gets fixed in the next versions?
I will record it and see what our bandwidth is to get a fix in the pipeline.
This issue is now being tracked here:
I am not sure if this is related or not, but I would like to mention two problems I have with the canvas save option.
This is a minimal example code:
Here are my problems/questions. If you look at the canvas save code, maybe these can also be addressed.
- I tried this on two android devices and I got two different saved image sizes (on my old android 5 phone the image is 200x100, on my android 10 tablet the image is 100x50, which is the canvas size). Why is the image size not the same as the canvas size, and why is it device dependent? I know that I can scale the image to a size that I want, but that is not an option, since I need lossless data transfer from canvas to image and two scaling (one at the time of the save) may result in information loss, especially if the save is in jpeg.
- When I press the button, the first time the code tells 0x0 image size. A second press of the button gives the correct size, but apparently the reading of the image size right after the canvas.save was run did not wait for the updated size. This is of course not a surprise, since it takes time to save and load something. I know I can use a timer (but then, I guess, the waiting time is also device and image size dependent, so how long shall I wait), but it would be nice to have a "when saved" block for the canvas or/and a "when image changed" block for the image (and everywhere where image can be used as a background).
Here is the file:
canvasSave.aia (2.3 KB)
The different sizes you are seeing are probably due to the different screen densities of devices. As I suggested, use an image extension to resize the image.
As I explained, image resizing is not an option, because information can be lost during resizing (even, when the resizing is done with a higher resolution and compression is done as a png).
I do not understand why screen densities of devices should effect the save size of a canvas. The canvas has a fixed size (200x100). Every pixel can be accessed individually. It is surely possible to save it as a 200x100 table of numbers (it can even be done with a double loop from app inventor using the getpixelcolor block, it just takes time). What is the reason behind not doing it like this in the background of the save canvas block?
size of the canvas (like 200*100), not in pixel, but in DP, so when saved as image, density will be involved.
Let me put it this way. As far as I understand, the visual information in a canvas is a 200x100 table of colors. Does the canvas.save option store a "screenshot" or does it store the information? If it stores the information, then it stores a 200x100 bitmap converted to a png or a jpeg. In this case I do not see any reason to change 200x100 to any other size.
you may try a 200 x 100 for loop, to get pixel color of each (x, y) to save in a list, then use drawpoint to re draw all the canvas, to check if the same canvas to be restored.
OK, I checked it now and it does not give back the same image when I do a loop and read the pixel colors from one canvas and save it to another canvas. I can see the difference between pixel and DP, but on the designer screen I set the size in pixels, not DP.
I can see some reasons, why it is set up like this, but it causes problems.
Here is my second experiment.
This one sets up a checkerboard pattern on the canvas and saves it as an image. This time the image is set to fill the parent (keeping the aspect ratio).
On my Android 5 phone with a small screen it looks good.
However, on my Simbans Picasso Tab Drawing tablet (Android 10, screen size 10.1'', screen resolution 1280x800) the canvas does not show the checker pattern and the saved image is the same blur, even when it is enlarged to fill the parent. The information is there (I specifically set the colour of each pixel) and on my Simbans tablet it is lost in the process of saving the image.
I really do think that it would be good to at least have the option of a device independent bitmap save to give more control to the developer.
canvasSave(1).aia (2.7 KB)