multithreading - mouse movements for background thread created windows forms -

i wondering if possible 1) hosting background thread created windows form inside application main thread created windows form ? or 2) separate thread processes mouse movements thread painting windows form application ?

i know these questions sounds crazy, find myself encountering peculiar problem , welcome advice of being able side-step problem, though not think can part windows forms , use different ui technology easily.

our software team writes plugins 3-rd party windows form application. provide root main form hosts bunch of user controls them, using api , host them in own windows form. user interfaces created on application's main thread, play nicely each other. many of our user controls provide have system.windows.forms.datavisualisation charts, painted live data application sourcing. 1 of problem have when user moves mouse around erratically display stop updating painting of graphs (gdi+) done on main thread ( use background threads , tpl sourcing , computing data, painting done on main thread). wondering if possible make gdi+ painting of these charts occur on different thread application main thread, painting continue , can still receive mouse movement inputs , clicks user interactions, erratic mouse movements can not flood message queue , stop gdi+ painting of user controls.

any specially, specially pointers relevant apis or articles demonstrating techniques appreciated. thank you.

it depends on cause of slow down when draw done.

first, should optimize drawing routines maybe painting entire form/control on each call onpaint? if that's case should re draw invalidated area, speed things lot.

else, if still need drawing on thread, cant directly, ui can modified on main thread, can use bitmap off screen buffer , re draw it.

to that, when control created create bitmap of controls size (also should take care of resizes). so, when change must done control's appearance, draw bitmap, can in thread, , invalidate control's updated area.

and finally, in control's onpaint blit bitmap control, , invalidated area, call still done on main thread, assure machine today able of blitting large images in milliseconds.

as example, let's suppose have control draw gradient background , circle.

usually, paint directly control surface through graphics object each time want update something, let's background, so, change draw full background , circle on it.

to in background, if created bitmap off screen buffer, don't draw surface, draw bitmap in thread (obtaining graphics object it) , invalidate updated área of control. when invalidate área onpaint called , can blit bitmap controls surface.

in step gained little or none speed, let's expand our example. suppose drawing complex control,with lots of calls drawimage, drawcircle, etc. when mouse moves on control, small áreas invalidated, , on each onpaint call draw "layers" composing invalidated área, can lots of draws if said control complex.

but if did draw bitmap controls appearance, on each onpaint call blit corresponding área bitmap control, see reducing calls lots of draws blit.

hope clarifies idea.