Is there a way to use an item as “picture frame” without reducing the quality of the image?
Is there a way to use an item as “picture frame” without reducing the quality of the image?
i mean it is possible to use a blank item and set a background to it, but this always reduces the quality which makes it almost impossible to enlarge it to screen size (or even bigger).
thanks
]]>
D5 Creation
< ![CDATA[
Try to split it into multiple ‘picture frames’.
Maybe someone that worked with images in script can make a script to split a picture in multiple items and place them.
]]>
< ![CDATA[
Writing a script that does not scale pictures down sounds easier to me 🙂
And furthermore i want to use it in combination with the parallax effect script so unfortunately this is not a solution to me…
]]>
< ![CDATA[
Indeed there is a limitation on the maximum background image size. It must be under 1M pixel.
Scripts are not affected by this limitation. Using LL.createImage, this will let you load bigger images that you can assign to an item background using Item.setBoxBackground.
You just need to remember that a large image require a large amount of memory.
References::
http://www.pierrox.net/android/applications/lightning_launcher/script/reference/net/pierrox/lightning_launcher/script/api/LL.html#createImage(int, int)
http://www.pierrox.net/android/applications/lightning_launcher/script/reference/net/pierrox/lightning_launcher/script/api/Item.html#setBoxBackground(net.pierrox.lightning_launcher.script.api.Image, java.lang.String, boolean)
]]>
< ![CDATA[
yes thank you. unfortunately i have no idea how to write a script. actually i can use them only since two days.
my idea was to use no wallpaper on a desktop but instead have an item in screen size with the parallax wallpaper script run from it. yet i still want to enjoy the high resolution of my device, so atm i cant use that setup. i dont know if thats too memory consuming so i just wanted to give it a try.
so…. might i be lucky if i requested a script like the one you described? 🙂
]]>
< ![CDATA[
Try this (run from an item)
LL.getEvent().getItem().setBoxBackground(LL.pickImage(0),”n”, true)
]]>
< ![CDATA[
TrianguloY I forgot about LL.pickImage! Great idea!
]]>
< ![CDATA[
thank you very much! it looks great!
]]>
< ![CDATA[
After a reboot LL loads the background picture for my hd item again in low quality. Is there any way the hd version can survive a reboot without me having to execute the script manually?
]]>
< ![CDATA[
Oh sh… Just checked the code, and there was a limit on image loading too, I totally forgot about that 🙁
When you assign an image through script limits are disabled, but when the launcher reloads its configuration through the standard path (the case at startup) limits are applied again 🙁
I definitely need to make something like this. I have big plans for an improve image management but in the meantime I think I will just add a switch to apply limits or not.
]]>
< ![CDATA[
I like big plans 🙂
Though the ability to decide not to apply limits would be appreciated. That’s what expert mode is there for any way.
Even when I don’t think that hd background images make sense on mobile phone devices (for battery and memory reasons) i guess that many tablet devices nowadays are powerful enough to handle those.
So thank you for your support, I’ll just wait for future updates of the launcher and keep my eyes open for a image quality switch 🙂
And thank you btw for developing LL. I love it!
]]>
< ![CDATA[
Indeed, those small gadgets are truly powerful. But memory is a strange beast. It is actually so complex that it is easy to get lost. Not sure that many users know the difference between VM, RSS and PSS.
Regarding Android, there is a per app memory limit. For instance on a N7 this is 192M (java heap), no matter whether the device has 192M free, 1GB or 3GB. A full HD image is ~8MB and unfortunately rendering it will need yet another 8MB. This makes a total of 16M. Let’s say someone would like to display a different picture in a 3×3 pages desktop (9 pages) and this makes a total of 142MB, leaving 50MB for everything else. That’s a lot. This is possible to store data outside of the java heap, but it has a performance penalty.
]]>
< ![CDATA[
can we use block compressed images, or at least RGB565 instead of RGB888 ?
]]>
< ![CDATA[
In theory yes but these images have no alpha and are probably converted to ARGB888 somewhere in the pipeline (I can be wrong). I am currently trying another way to solve the issue.
]]>