SWT: How to “render” a Widget in the background / into an offscreenbuffer - swt

Question

I would very much appreciate your advice and help:
How can I render a SWT Widget/Component in the BACKGROUND (offscreenbuffer?) and get the “painted” pixels that were drawn by the Widget/Component to save them on the harddisk:
What I currently have is:
Display display = new Display();
Shell shell = new Shell(display);
// ...
MyWidgetComponent mwc = new MyWidgetComponent(shell, SWT.BORDER);
shell.open();
Image screenshot = new Image(shell.getDisplay(), shell.getBounds());
GC.copyArea(screenshot, 0, 0);
//...
Problem:
Taking the screenshot itself of the shell/widget works, but it will open a new Window in the Taskbar. That is something I do NOT want.
What I want to achieve is:
I want to run this application completely in the background as a “server application” (for example embed and call this into a servlet). So the MyWidgetComponent should be rendered pixel by pixel completely in the offscreenbuffer and I later I retrieve the pixels and save them to the harddisk or directly return the rendered widget as an image as the result of the servlet-request. (I do not want to popup any windows in a server environment, in case this might be a windows server...).
How can I achieve this. I searched a lot but havent found anything useful.
Thank you very much!!
Jan

Answer 1

I can't answer your question directly, but I have run into a similar problem that I struggled with: taking a screenshot of a Shell or Widget while it is obstructed from view.
Consider, for instance, window A that overlaps window B. A screenshot is made of B using your code:
Image screenshot = new Image(shellB.getDisplay(), shellB.getBounds());
GC.copyArea(screenshot, 0, 0);
My findings revealed that this could be done under Windows Vista, Windows 7 and Mac OS X (although I'm unsure about the latter). However, under Windows XP, Linux with GNOME and Linux with KDE, the screenshot contains a white area where the overlapping window obstructs the view.
I haven't found a solution for this, and I suspect that not only is this behavior platform dependent, but also fairly buggy in SWT.
I'd love to hear that I'm off the mark, though!