v10.5 (release candidate)
v10.5 (release candidate)
This is published as a beta but I will promote it to the production channel if nothing prevents it.
Just a couple of minor changes:
– when scaling widget, round new sizes to the nearest integer (previously: truncated). That’s a refinement that should have a very limited impact.
– pickcolor renamed to pickColor (camel case), add a “title” parameter to pickColor and pickNumericValue (this is an incompatible change but since these functions have been introduced 3 days ago it shouldn’t be too much a problem).
]]>« About 14 days I have problem with not working LL. (Previous Post)
(Next Post) Fun with widgets as only LL can. »
D5 Creation
< ![CDATA[
I thought we were on 10.5.4b now. Did Google just kick me from the beta test?
]]>
< ![CDATA[
No, I just name beta with the future release index, and then I add a suffix b1, b2, etc. This one is in beta but is probably (or maybe not) stable enough to become the final 10.5, hence I dropped the suffix. Google has a mechanism to move a build in beta to the production channel.
]]>
< ![CDATA[
So it is a beta just but more of an alpha version of the beta?
]]>
< ![CDATA[
An almost release quality version of the beta (a release candidate)
(although I just learned from TrianguloY that a critical bug is hidden somewhere…)
]]>
< ![CDATA[
Uh oh. Ouch where is the bug so I know where not to look?
]]>
< ![CDATA[
It’s a complex and strange one.
Just a desktop full of random items (my testing desktop) some scripts here and there, and custom backgrounds in some items.
It worked ok…But suddenly now I can’t go to that desktop nor open the configure desktop screen (it freezes) so it seems to be a render bug. (How to avoid it? … no idea)
]]>
< ![CDATA[
So it could happen to me at any point and seeing as I only have 1 desktop I’d be fucked (for lack of better term sorry )
]]>
< ![CDATA[
I’ve been testing in that desktop since months ago and I tried a lot of things, even with intentional crashing scripts.
My normal main desktop is ok so with a normal use it shouldn’t happen anything.
Just make a backup from time to time (it’s a good practice) and don’t worry
]]>
< ![CDATA[
Sounds like a good idea.. Seems ok right now so if there’s a bug I’m not seeing it yet
]]>
< ![CDATA[
bug fixed!
]]>
< ![CDATA[
Yay! Could I ask what it was?
]]>
< ![CDATA[
This was linked with the new tag + id method. There is a case when reading the list of tag ids returns null, but I thought it would return an empty list. I wasn’t expecting this, although it was clearly documented.
]]>
< ![CDATA[
All that over a null exception?
]]>
< ![CDATA[
With the scaling widget the truncated (I don’t know what that meens) method was better. Now I have on every zoopet widget a border of -1 pixel. With the truncated method only the widgets in Panels had that one pixel problem. I will try to make a screenshot but my LLX keeps crashing after I load a template. It crashes so hard that my phone reboots, the battery notification switch to 0%, and after a few sec. the phone shut completely off and have to recharche.
]]>
< ![CDATA[
Roger Schreuders
Truncated: 0.1=>0 0.5=>0 0.99=>0
Rounded: 0.1=>0 0.5=>1 0.99=>1
]]>
< ![CDATA[
Pierre Hébert For scaling, are you using truncate? Just received my OnePlus One and applied my WIP template from Nexus 4 (768×1280 to 1080×1920). Scaling went from 50 to 46, resulting in too small widgets. 47 would’ve been correct, this is also what ZW decides when reloading manually.
Strange is also the applied template lags a lot at first. LL even hangs completely, often crashes. Seems related to dettaching items. Once all (or most) are dettached, it’s fast and stable again. Attached them for safer “migration” to different devices. Need to rethink that… But think it wasn’t that bad before. Also many widgets and icons show errors until settled (or multiple LL restarts).
]]>
< ![CDATA[
Yes truncation is applied on width, height and scale. But maybe only width and height should be truncated and scale rounded.
Regarding the lag, icons and widgets error and crashes are all from the same issue. Out of memory. This is something I don’t know how to fix yet. Here is a brief explanation:
– The android widget framework is the glue that “links” the widget provider (zooper) and the widget host (llx).
– The widget provider provides the widget content, while the widget host displays this content
– From time to time the widget provider sends an update for the widgets it manages (it includes buttons, images, etc.)
– The android widget framework takes care of handling this update in the launcher side, this is a black box.
– In the case of zooper, the widget updates contain a lot of bitmaps. This is understandable because zooper being a customizable widget, it relies a lot on bitmaps since it enables custom content of course.
– But… as always, bitmaps cost a lot of memory
– The available virtual machine memory is limited for each app. This is the memory allocated to the “java” app, not the memory used by the process. The VM memory is usually limited to 64M, 96M or 128M.
– The problem is that bitmap memory grows with the square of its size, and the size is usuall linked with the size of the screen.
– On one hand the bitmaps grows very rapidly, on the other hand the VM memory budget doesn’t.
– And this is where the problem is: custom widgets requires a lot of memory, and the use of this memory cannot be really controlled on the launcher side because it is allocated in this black box which is the android widget framework.
]]>
< ![CDATA[
Pierre Hébert Thanks for the detailed insights. Seems I’m using to many widgets which on large screens result in memory problems. DAMN!! Have to rethink my whole concept for optimisation…
Fluid and fast on “small” Nexus 4, jerky and faulty on big and powerful OnePlus One. Wondering how if ever it would work on Nexus X (1440×2560 screen!!).
]]>
< ![CDATA[
Yes, this high res stuff is really becoming an issue.
]]>