Threading issues

[MichaelSpectre]

This is gonna be difficult to summarize, but I'll try my best...
I'm developing a graphics engine as extra credit for one of my classes. I'm using a balanced mixture of managed objects, GDI+, and Win32 API methods.
Some of the classes I have are as follows:

- Canvas (Device context/Memory Bitmap, for rendering to a PictureBox control or to another Canvas object using Bitblt)
- SpriteImage (Device context/Memory bitmap, for rendering to a Canvas)
- Sprite (Manipulation of a SpriteImage within a Canvas)
- GameThread (Holds a collection of Canvases, SpriteImages, Sprites, etc, to be passed between threads)
- Game (The base class, which initializes a timer, a GameThread, a new System.Thread, and starts the main loop)

The problem I'm having is accessing and changing data for the thread that the Game object creates, and passing it to the main thread so the Form can update itself accordingly, i.e. setting it's text property to inform the user about the state of certain objects.
The concept here is to allow the developer to create a Game instance (passing the form's PictureBox as a parameter), add a few SpriteImages to it (via the Game's GameThread instance), then have the Game object render everything to the screen from within the PictureBox's paint event on the main thread.
It's crucial to allow things to happen this way, because the Canvas object's Render() method requires the PaintEventArgs to borrow a valid handle to the PictureBox's device context before anything can be rendered to it.
Also, since the main thread is entirely event-driven, and the Game object starts a constant loop which runs on a separate thread, the only way I can think to connect the two is by raising events from the Game class to the main form.
But I can't seem to get around the cross-threading issues, since not everything can be created on the same thread.

I don't want to have to resort to forcing the developer to deal with creating his own thread on the main thread, and even if I did then I'm not sure if the PictureBox's paint event will cause the same issues I'm having now.
The whole reason for creating the Game class was to manage objects for the developer, and have everything running on a separate thread so it doesn't bog down the main thread's user interface (and allows the PictureBox to redraw correctly so that it's PaintEventArgs doesn't end up being null).
And if I make everything event-driven instead, then there's a loss in efficiency and it might also force the developer to write more code on the main thread than he needs to.

So how can I get this to work?
Any advice or new concepts will be greatly appreciated.
And if anyone needs more info, please ask!

 

[MichaelSpectre]

If it helps, here's a (poorly) illustrated example of how things are currently set up. Kinda.

 

[MichaelSpectre]

Nevermind. I've decided to knock out the middle man and create my own window via CreateWindowEx, so there's no more need to rely/wait on the paint event and there's much less weight involved overall.

 

[Herman]

For future reference, to avoid having to deal with delegates to pass data back to the main thread, custom events are easy to work with and let you pass any data whatsoever.