It is fixed by replacing Manager::ProcessPendingEvents() with Manager::Yield() (right after the splash creation).No difference here.
Could you try adding a call to Update() after Show(true) and see if it does the trick for Windows?That seems to fix it for me, no artefacts.
GDA seems to be offline and it could take the whole weekend (elections are this weekend and the University will be an information center), so the new links are:
Screenshot (http://img513.imageshack.us/img513/8616/snapshot13nl.png).
Files (http://ceniza.cenizasoft.cjb.net/CodeBlocks/splash/).
EVT_ERASE_BACKGROUND(cbSplashScreen::Null)
void Null(wxEraseEvent &){};On some platforms, such as GTK+, this event is simulated (simply generated just before the paint event) and may cause flicker. It is therefore recommended that you set the text background colour explicitly in order to prevent flicker. The default background colour under GTK+ is grey.
On GTK+, use of wxBG_STYLE_CUSTOM allows the flicker-free drawing of a custom background, such as a tiled bitmap. Currently the style has no effect on other platforms.
This function tells a window if it should use the system's "theme" code to draw the windows' background instead if its own background drawing code. This does not always have any effect since the underlying platform obviously needs to support the notion of themes in user defined windows. One such platform is GTK+ where windows can have (very colourful) backgrounds defined by a user's selected theme.
The window is transparent, that is, it will not receive paint events. Windows only.
Don't use this window as an implicit parent for the other windows: this must be used with transient windows as otherwise there is the risk of creating a dialog/frame with this window as a parent which would lead to a crash if the parent is destroyed before the child.