image displaying incorrectly #5184
Replies: 1 comment
-
Posted at 2022-09-06 by @gfwilliams Do you think you could post up the image (as base64) as well as the draw command so I can take a look? What's with What if you do just Posted at 2022-09-06 by NoMusicTuesdays Thanks for the quick reply. Yes, it should read 133. I typed 1333 by accident when manually replacing my variable value to simplify things for this thread. I'll attach a picture of the results of And here is the base64:
Attachments: Posted at 2022-09-06 by NoMusicTuesdays Just for kicks I tried using the base64 in my code, and that works fine. Is there a performance difference between doing that and calling up an image stored on the device? Posted at 2022-09-07 by @gfwilliams
Ahh, that's interesting, thanks! I just tried here and I can reproduce, and I think the issue is if you're using a paletted image and loading it from flash, it maybe calculates the image start offset wrong. I'll see if I can get a fix in for that.
Yes - it's a hard one to quantify - but if you have the image in RAM all the time (eg as a global variable, rather than with the base64 inside the function that renders it) then it'll be much faster. Since you're using 'optimal 2 bit' the image should be pretty small, so I'd say maybe keep it (and the other hands too) in RAM, and it'll make the clock face update much faster. ... but I'll see what I can do about the image loading issue anyway Posted at 2022-09-07 by @gfwilliams Quick update - it's actually a bug in the Web IDE's image uploader! It actually got fixed a while ago (espruino/EspruinoWebTools#9) but unfortunately hasn't made it into the IDE yet. I'll try and get a release done soon... If you do:
it'll write the correct image and it should then work for you Posted at 2022-09-08 by NoMusicTuesdays Oh, good to know about that last manual conversion/upload thing. And I actually haven't had a chance to test any of this on the physical js1 yet since I can't seem to find the charging cable. I did move all the hands to base64, but yeah the larger face images in base64 crashed the emulation. So for the larger images, if I declare them as global variables outside of the function, would I be better off declaring that variable as Or is it in RAM? We had previously discussed elsewhere that
Does that hold true for the global variables? Posted at 2022-09-09 by @gfwilliams
:) As you say, However, while it is slower than RAM, it's still a lot faster than using Posted at 2022-09-09 by rigrig Am I right in thinking there is a difference between Offtopic: now I'm thinking about storing multiple images (uncompressed) into a single file, using either Posted at 2022-09-09 by @halemmerich I have got good results using offsets and writing all image-data into one file in my imageclock app. The offsets/metadata are created beforehand in the customizer on watchface upload to allow different resolution images in the big file and stored in a specific json alongside the big resource file. On use they are converted to image objects in app.js#L84 and drawn in app.js#L287 Posted at 2022-09-12 by @gfwilliams
Yes :)
If you're just using In @halemmerich's case he has loads of images - but for just 3 images I don't think it's really worth it Posted at 2022-09-12 by rigrig Well, I was also thinking about how it bugs me that images are now included as basically read-only binary strings, and how it would be nice to have some way to just add them as image to the repository, without having to update both the image and the string when editing. Posted at 2022-09-13 by @gfwilliams
The IDE can convert images as it uploads, so in theory the app loader could maybe allow images to be converted on the fly. The problem is to get the best performance you really need to choose what image type you need - there's no point storing black and white images in 16bpp. IMO hiding all that away makes it far more likely we end up with slower, more memory-inefficient apps Posted at 2022-09-13 by rigrig Yeah, I don't really see a good solution for it. (but I'll try to at least add the source images I use to the repo) Posted at 2022-09-14 by NoMusicTuesdays After some testing with the clock hands, I find that |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-09-06 by NoMusicTuesdays
I've been very thorough and I can't figure out what's going on here.
The picture on the left shows my image (the minute hand of the clock) as it should look, the one on the right shows how it's coming out in the emulator. My second and hour hands are working fine, but for whatever reason, the minute hand image just looks crazy! All three images were created from the same photoshop file, using two colors plus transparency, and I've tried saving with every possible option and file type that supports transparency. For all three I used the "optimal 2 bit" option in the uploader, with transparency on. I can't figure out why the other two work just fine but not this one.
g.drawImage(require("Storage").read("MinHand.png"),120,1333,{scale:1,rotate:0});
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions