Summary: | Direct instantiation of SWTGraphics in DeferredUpdateManager | ||
---|---|---|---|
Product: | [Tools] GEF | Reporter: | Peter Severin <peter_p_s> |
Component: | GEF-Legacy Draw2d | Assignee: | Anthony Hunter <ahunter.eclipse> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | ahunter.eclipse, hudsonr, Thomas.M.Crockett |
Version: | 3.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Peter Severin
2006-06-12 11:29:46 EDT
This is an easy fix to implement, but it is an api change to expose the graphics creation. I guess the question is - how likely is it that an existing client has implemented the method signature createGraphics on an overriden DeferredUpdateManager class? Yes, a createGraphics method in DeferredUpdateManager would do the trick. The ideal solution should delegate this to the GraphicsSource interface. A Java2D based Graphics implementation works a bit differently as it draws on a BufferedImage which is at the end is transferred to the SWT drawing context. This means that I should add some workaround into the Java2dGraphics.dispose() method (because the DeferredUpdateManager calls this at the end of its paint method) to do it instead of doing it in the GraphicsSource.flushGraphics as before. Perhaps a clean solution can be considered for Eclipse 3.2.1 (In reply to comment #2) > Yes, a createGraphics method in DeferredUpdateManager would do the trick. But then you have to subclass the updatemanager, which is bogus. That's the whole point of the graphicssource: to avoid subclassing. We could change paint(GC) to do an instanceof NativeGraphicsSource check. If it is native, create the SWTGraphics. Otherwise, call super#paint(GC), which will use the client's GraphicsSource. Unfortunately, GraphicsSource is an interface instead of a class, so we can't add getGraphics(GC). (In reply to comment #3) > We could change paint(GC) to do an instanceof NativeGraphicsSource check. If it > is native, create the SWTGraphics. Otherwise, call super#paint(GC), which will > use the client's GraphicsSource. It looks like a good compromise. Just please make sure that the super#paint(GC) works as expected. I've tried to override the LightweightSystem#paint(GC) method to make it function like it was in previous versions: public void paint(GC gc) { manager.performUpdate(new Rectangle(gc.getClipping())); } It didn't work and I was getting a white area that wasn't repainting. I believe the super#paint(GC) will be equivalent to the above. *** Bug 159892 has been marked as a duplicate of this bug. *** Unset target milestone as the specified one is already passed. |