IOS change concurrent with the recent server upgrade
42 views
Skip to first unread message
Dave Dyer
Oct 5, 2016, 10:51:14 PM10/5/16
to CodenameOne Discussions
I've noticed a change, starting about the time the IOS build servers were changed over
to the current scheme, which appears to be some very low level difference in the
treatment of resource loading.
The two symptoms I notice is that loading a resource file in a background thread
now seems to cause a complete stall, all processes are frozen, until the load
completes. I notice this because at the point the background process is triggered,
the UI freezes in a state that's hard to attribute to normal processes. The second
symptom is that a load-on-demand scheme for resource images, which can result
in the same resource file being reloaded several times, now seems to cause a hard crash.
I'm still investigating, but if this description triggers any "aha" or "oh shit" reactions,
please share what you can.
This affects IOS only. Simulator and Android are not affected.
Dave Dyer
Oct 12, 2016, 9:11:09 PM10/12/16
to CodenameOne Discussions
Closing the loop on this; the flickering, frozen UI turned out to be because
loading images from a resource file was occurring in a user thread. It's unclear
why loading images should be an EDT process, and it seems undesirable
to me that such a CPU and IO intensive process should run there.
The hard crash attributed to loading images on demand turned out to be a
code generation bug (of yours) which I have filed a issue and test case.
Shai Almog
Oct 12, 2016, 9:59:31 PM10/12/16
to CodenameOne Discussions
This should work fine in the user thread. If there is a test case we'll look at that.
Dave Dyer
Oct 13, 2016, 1:51:46 AM10/13/16
to CodenameOne Discussions
It works, but the redisplay of unrelated content in the EDT thread is damaged.
Lots of things related to manipulating images trigger EDT violation warnings. It
may be the case that actual loading is harmless but subsequent manipulation
to prepare the images for use is causing the damage.
Lots of things related to manipulating images trigger EDT violation warnings. It
may be the case that actual loading is harmless but subsequent manipulation
to prepare the images for use is causing the damage.
Dave Dyer
Oct 13, 2016, 2:16:52 PM10/13/16
to CodenameOne Discussions
Shai Almog
Oct 13, 2016, 11:24:14 PM10/13/16
to CodenameOne Discussions
I looked at your issue and it looks like you do things such as getRGB on a separate thread and not just loading... Some of these methods require global OS context so you can't do them off the EDT.
Dave Dyer
Oct 14, 2016, 12:08:13 PM10/14/16
to CodenameOne Discussions
Presumably some more elaborate scheduling of the use of global context could
occur under the hood.
occur under the hood.
Dave Dyer
Oct 14, 2016, 12:09:57 PM10/14/16
to CodenameOne Discussions
For example, these are intrinsically slow operations, so the cost of using ordinary synchronization is unimportant.
Shai Almog
Oct 14, 2016, 10:43:37 PM10/14/16
to CodenameOne Discussions
You can do that scheduling in your thread and just mix callSeriallyAndWait() into your thread for those problematic calls.
Doing it implicitly is "problematic".
Doing it implicitly is "problematic".
Reply all
Reply to author
Forward
0 new messages