| Summary: | [Canvas] Implement SWT.NO_BACKGROUND to avoid clearing the canvas rectangle | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Arian Storch <storch> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | ASSIGNED --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | linuxhippy, tbuschto |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 370313 | ||
| Bug Blocks: | |||
|
Description
Arian Storch
So you would like to draw on top of everything else, never clearing anything you have drawn. Is that correct? Could you use two Canvas on top of each other, one for unchanging background, the other for dynamic content? (In reply to comment #1) > So you would like to draw on top of everything else, never clearing anything > you have drawn. Is that correct? Could you use two Canvas on top of each other, > one for unchanging background, the other for dynamic content? This could be a solution. But nevertheless the foreground canvas needs to have a transparent background otherwise the background canvas isn't visible. This would be very useful for clientside scripted painting. The only issue i see is that for IE7/8, the number of shapes would continue growing. To solve this, IE could detect if a rectangle is drawn over the entire area, effectively clearing the canvas. Arian, could you try RAP 3.1M5? We don't clear the complete canvas anymore if redraw(x, y, width, heigth) method is used. I guess I am also bitten by this issue ... I am currently trying to write a widget and ran into this issue too. I would like to do most of the rendering on the server, but allow client-side selection of objects in a MouseDown ClientListener (overdraw the content created on the server-side). Inside the MouseDown handler I do not have access to a gc (event.gc is null), so I call redraw() there - which clears the canvas no matter what arguments I pass and regardless of SWT.NO_BACKGROUND set. I worked arround the issue by preserving the GC during paint, and performing draw calls inside the mouse handler, but I would prefer a proper way of solving this issue... |