GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Although events generated by System::Tick are handled while the rendering thread is suspended, the MouseEvent, KeyboardEvent, and Net IO events handling can run parallelly with rendering thread, resulting in inaccordence with adobe flash player.
Especially, this means that DisplayObjects can change in the middle of rendering, which lead to noticable flicker and artifacts.
It also requires us to use a lot of locking between Render thread and VM thread.
Actually DisplayObjects cannot change in the middle of rendering. The flickering comes from a different porblem. DisplayObjects are rendered from their CachedSurface which represent the OpenGL texture memory where it has been uploaded the last time. Since only the render thread itself can upload new data to the textures is pretty clear that the rendered state is not influenced by VM actions
But Display objects can change while they are written to the CachedSurface. Especially the display hierarchy can change while it is written to their CachedSurfaces.
The cached surfaces are generated from a snapshot of the data taken from each invalidated object after the event being handled is completed. So the state is consistent. (This is actually not true for Bitmaps, since the BitmapData contents are not copied. I plan to fix this using a copy on write strategy). Still you are right that the display hierarchy can change and this is a bug. I think it's better to implement a sane COW strategy than completely synchronizing the render thread with the VM thread. Anyway I definitely think the flickering we can see is not caused by changes in the display list hierarchy.