Status Update
Comments
ap...@google.com <ap...@google.com> #2
This is occurring due to the usage of the BundledSQLiteDriver
that loads a native file (JNI).
A small workaround you can try is to create a wrapper driver that initializes the actual one later when a connection is being opened in a background thread, delaying the initialization of the JNI library:
class BundledSQLiteDriverWrapper : SQLiteDriver {
private val actual by lazy {
BundledSQLiteDriver()
}
override fun open(fileName: String): SQLiteConnection {
return actual.open(fileName)
}
}
ap...@google.com <ap...@google.com> #3
hey , Do I really have to do that ? . It is not hurting my application at all . I was just taking some clarity on to why it is occurring which you provided.
Just dont want to run into any problems in the future since we just freshly started working with Room KMP .
Please do let me know if I should attempt a solution like you have provided or if its fine the way it is .
na...@google.com <na...@google.com> #4
If you don't perceive the disk read as an issue during startup / database initialization then you don't have to do the workaround. I provided it in the mean time if it was hurting your app while we try to make a fix.
Description
Some more details in b/388353336
Start of trace:
This happens because when we draw we use a shared ContentDrawScope implementation that we render all DrawModifierNodes in. We do this by mutating a property as we draw successive nodes. However, this means that if anyone captures a reference to this draw scope and tries to draw it later on, this will cause a NPE error as we don't know what the 'current node' that needs to be drawn in.
For the general case this is an error and scopes shouldn't be captured and stored outside the scope in this way, but for GraphicsLayer this is needed when recording drawContent to support some edge cases, such as when we need to draw a layer implementation that can't be drawn in software, within software rendering (such as drawing to a Bitmap). For this we just end up re-invoking the draw block we captured.
We considered some solutions where we would allocate a new draw scope instance per modifier, but this adds some overhead and 'storing' these draw scopes for future use is challenging. (we considered putting them on the node object, in a map on the node coordinator, or some other chain structure on the node coordinator, but none of these are really great)
Instead we can explicitly support the GraphicsLayer.record case by overriding the DrawScope#GraphicsLayer.record function and making it handle this case properly. This can still cause issues if using the non-DrawScope scoped record function, but developers should move to the DrawScope one instead.